Improve error reporting: Member implementation with tuple argument(s)

[JanWosnitza]

Related to #1200

What

There is a difference between int32 * int32 -> unit and (int32 * int32) -> unit. The first one generates 2 parameters and the second one generates 1 tuple parameter. One might stumble upon this error:

type IInterface =
    abstract Function : (int32 * int32) -> unit

{ new IInterface with
    member this.Function (i, j) = ()
}

FS0768: The member 'Function' does not accept the correct number of arguments, 1 arguments are expected

Why

The error message is confusing, because one might not expect the brackets to change the overall function signature and assume to the result as with:

type IInterface =
    abstract Function : int32 * int32 -> unit

{ new IInterface with
    member this.Function (i, j) = ()
}

How

Trying to address @forki proposals ( #1200 (comment) ):

• it should be singular
• it could hint the signature of Function
• it could tell something about tuples vs. "C# style parameters"

E.g.:

FS0768: The member 'Function : (int32 * int32) -> unit' does not accept the correct number of arguments. Expecting 1 argument
    (int32 * int32)
but given are 2 arguments
    int32 * int32
Member functions with a single tuple argument are compiled to C#-ish parameters instead of a single parameter of type tuple, unless forced otherwise.

I am unsure about the "tuples vs C# style parameters" explanation (also a native speaker should choose the exact wording :) )

[JanWosnitza]

erm.. oups

[forki]

would that help:

?

I assume we would need to remove the word "abstract" from the message. and then it would already be better.

[forki]

But we still somehow need to explain the tuple issue.

[forki]

WIP PR in #1229

[forki]

like this?

[forki]

related PR: #1230

[cartermp]

I'm leaving feedback about the error message here rather than in the PR so that code can be what's discussed there.

I like your initial changes @forki. I've bolded my suggestions.

Before:

The member 'Function' does not accept the correct number of arguments. 1 argument(s) are expected. The required signature is 'member IInterface.Function: (int32 * int32) -> unit'.
A tuple type was required in one of the parameters. Consider to put the given arguments in additional parentheses.

After:

The member 'Function' does not accept the correct number of arguments. 1 argument(s) are expected, but 2 were given. The required signature is 'member IInterface.Function: (int32 * int32) -> unit'.
A tuple type is required for one or more parameters. Consider wrapping the given arguments in additional parentheses.

My rationale for these suggestions:

• I think that specifying the number of arguments that were passed clarifies the mistake
• I think that changing from past to present tense is a bit clearer.

Thoughts?

[vilinski]

Just some naive thoughts.
The elm compiler gives sometimes the code examples. I think here it will be extremely useful also, with some explanation e.g. why there is just one argument expected and (i, j) are two, and how to make them one.

Consider wrapping the given arguments in additional parentheses:
(some code)
or fix the interface definition:
(some interface code)

[JanWosnitza]

@cartermp mentioning the given amount would be incredibly useful.

And also printing the given signature would help with understanding what's wrong with the given implementation (as I proposed initially):

The member 'IInterface.Function' does not accept the correct number of arguments.
The required signature has 1 argument(s):
    (int32 * int32) -> unit
but the given implementation has 2 arguments:
    int32 * int32 -> unit
A tuple type is required for one or more parameters. Consider wrapping the given arguments in additional parentheses.

@vilinski I believe this would require special case checking. But if you start adding them to some messages people might start to complain about all the other missing special cases. It's going to be a never ending story. (Though I don't know if they started similar stuff on other messages.) IMHO the compiler should print only enough information to be able to clearly understand what the problem is. Your drawn conclusion may greatly differ depending on what you trying to do.