In other words: it should be possible to make the last positional arguments optional in a subclass.

Removed Type-Defect label.
Added Type-Enhancement, Area-Language, Triaged labels.

The spec says:

It is a compile-time error if an instance method m1 overrides an instance member m2 and m1 has a different number of required parameters than m2. It is a compile-time error if an instance method m1 overrides an instance member m2 and m1 does not declare all the named parameters declared by m2 in the same order.

Therefore the reported behavior is correct.

This comment was originally written by @seaneagan

This should apply to function types in general, not just methods (with issue #1616 methods would not be a special case).

Assume we have the following function type:

typedef F(a, b, [c, d]);

The following should be subtypes of F:

typedef G(a, [b, c, d]);
typedef G([a, b, c, d]);

I would take this a step further and say that (as in JavaScript) when a function (or method) is called with extra positional or named arguments, then instead of calling noSuchMethod on the function or method receiver), just ignore the extra arguments. There of course should still be a static warning for this.

Then the following would also all be subtypes of the above function type F:

typedef G(x, y, [a]);
typedef G(x, [y, a]);
typedef G([x, y, a]);
typedef G(x, y);
typedef G(x, [y]);
typedef G([x, y]);
typedef G(x);
typedef G([x]);
typedef G();

The big use case for this is registering callbacks which will be passed arguments which you don't care about, and thus do not want to include in the formal parameters of your callback. For example, as with JavaScript's Array, Dart's List could add an "index" parameter to all of it's higher order methods (forEach, filter, map, every, some, etc.), for example:

void forEach(void callback(E item, int index));

allowing for things like:

list.forEach((item, index) => print("$index: $item"));

while still allowing for:

list.forEach((item) => print(item));

Also it would allow callbacks passed to Future#then where the future does not produce an actual value, to omit the "value" parameter.

This comment was originally written by amatia...@gmail.com

Comment #­3 - @­seaneagan1:
I don't agree

typedef G();

To be a subtype of

typedef F(a, b, [c, d]);

If at F I defined a and b as mandatory at least you function must be able to handle this arguments:

typedef G([a, b]);

This can be a subtype.
If you want to not force a handler to recive a argument you can do it optional:

void forEach(void callback(E item, [int index]);

With this the function

void myCallback(item);

Should be a valid callback for a forEach because it's a subtype of the expected callback.

This comment was originally written by @seaneagan

I agree that it shouldn't be a "subtype" per se when parameters are missing, and a static warning would help catch errors, but at runtime it shouldn't call noSuchMethod, but instead ignore the extra arguments passed. My basic argument is that, as in JavaScript, you shouldn't have to declare parameters that you don't care about, similar to how you don't have to declare types you don't care about.

This comment was originally written by amatiasq...@gmail.com

Javascript does not have optional arguments, dart does.

This comment was originally written by @seaneagan

JavaScript has optional arguments, what it doesn't have is required
arguments:

function greet(name, salutation) {
  // salutation is optional, so default if falsey
  salutation = salutation || "Hello";
  alert(salutation + ", " + name);
}

greet(); // alerts ", " and and no error since JS does not have required
arguments

This comment was originally written by amatiasq...@gmail.com

And that behaviour dart implements it as optional arguments.

So the new behaviour are the non-optional arguments, so we cannot compare them with Javascript.

If you want Javascript-like behaviour you can use optional arguments.

This comment was originally written by amatia...@gmail.com

I mean, whay do we have optional and non-optional arguments if you want to make they all optional?

This comment was originally written by @seaneagan

I'm not talking about making the passing of arguments optional, we already have that. I'm talking about making the declaration of trailing (required or optional) arguments optional when registering callbacks or overriding methods, and then merely ignoring any extra arguments passed at runtime instead of treating it as though the "call" operator is not supported, when in fact it is.

This comment was originally written by amatiasq...@gmail.com

I know you are not talking about passing of optional arguments, me neither, I'm talking about if I said that parameter is needed it's because you must recive it, otherwhise this could be a error, for example:

File.exists(() => print("LOL!"));

If the argument is not mandatory I should set it as optional so you are not forced to recive it.

Set owner to @gbracha.
Added Accepted label.

This comment was originally written by @seaneagan

@12:

I agree that in that particular case, it doesn't make sense to ignore the argument, but there are many cases where it does, and as I mentioned above you should still get a warning there.

This comment was originally written by micaela...@gmail.com

In this case I must set this arguments as optional, so you can ignore them.

void File.setContent(string value, void handler([Date modificationDate]));
void File.exists(void handler(bool result));

File.setContent("asdfasdfasfd", () => print("DONE"));
File.setContent("asdfasdfasfd", (modDate) => print("DONE"));
File.exists((result) => print("Callback"));
File.exists(() => print("Callback")); // ERROR

In the case of forEach it should be

void List.forEach(void handler(item, [int index, List self]);

[ 1, 2, 3 ].forEach((item, index, list) => ...);
[ 1, 2, 3 ].forEach((item, index) => ...);
[ 1, 2, 3 ].forEach((item) => ...);
[ 1, 2, 3 ].forEach(() => ...); // ERROR

This comment was originally written by @seaneagan

void forEach(void handler(item, [int index, List self]);

this implies that the List implementation may omit some arguments when calling your handler, which is not true.

[ 1, 2, 3 ].forEach((item, index, list) => ...);
[ 1, 2, 3 ].forEach((item, index) => ...);
[ 1, 2, 3 ].forEach((item) => ...);
[ 1, 2, 3 ].forEach(() => ...); // ERROR

I think they should all be static type warnings, but that the passed handlers should still get called, and just ignore the extra arguments being passed to them by the List implementation.

This comment was originally written by amatias...@gmail.com

Ok, I see what you mean, optional arguments have another meaning, but I don't see to allow ignore non-optional parameters to be better

Added Duplicate label.
Marked as being merged into #2706.