Lambdas should be subtype-compatible with practically compatible types

[nex3]

Currently it's illegal to assign functions with signatures of "foo([arg])" or "foo(arg1, [arg2])" to a callback that expects the type "foo(arg)". This is less than optimally useful.

[peter-ahe-google]

The reason for the current rule is that we are also using it for whether or not a method can override another. These rules could be separated.

In addition, considerations needs to be made to what happens, in general, if you pass too many arguments to a function.

Before we make any changes to function subtypes, we should consider if a special way to specific and invoke callback/event-handlers would be better.

The typical example where this is painful is:

model.onEvent = (ignored) => respondToEvent();

Most people think this will work:

model.onEvent = respondToEvent;

---

cc @larsbak.

[munificent]

I believe we're talking about two different changes here.

1. The issue we ran into with pub is that foo([arg]) is not a subtype of foo(arg).
2. I think you're proposing that foo() be a subtype of foo(arg).

I'm in favor of both of those (I'm strongly in favor of the latter since I often have to create throwaway parameters to get around its absence).

[munificent]

Issue #7777 has been merged into this issue.

[lrhn]

The first case (assigning signature ([int])->int to type (int)->int) is a known restriction and allowing it is being discussed.

The second case (assigning signature (int,[int])->int to type (int)->int) is already allowed. If it gives warnings or errors, that's a bug in the implementation.

Our type system can't allow assigning ()=>42 to something excpecting (int)->int. You have to use untyped/Function-typed code for that. If it did allow it, it would be worthlesss as a type assertion.

There is currently not a way to call a function that ignores parameters that are not expected by the function (or supplied parameters necessary for the function). I'm not sure it would be a good thing.

[peter-ahe-google]

"There is currently not a way to call a function that ignores parameters that are not expected by the function (or supplied parameters necessary for the function)."

I beg to differ. There is a way, it's just very annoying:

typedef OneArgOneOptFunction(a, [b]);
typedef TwoOptFunction([a, b]);

typedef OneArgFunction(a);
typedef OneOptFunction([a]);

typedef ZeroArgFunction();

callClosureWithOptionalArguments(f, a, b) {
  if (f is OneArgOneOptFunction || f is TwoOptFunction) return f(a, b);
  if (f is OneArgFunction || f is OneOptFunction) return f(a);
  if (f is ZeroArgFunction) return f();
  return f(a, b);
}

[gbracha]

Set owner to @gbracha.
Added Accepted label.

[alan-knight]

Issue #8964 has been merged into this issue.

[alan-knight]

This also comes up with map, e.g.

foo([String s]) => (s == null) ? 0 : s.length;
someList.map(foo);

[gbracha]

We should fix this. The VM has no problem dealing with this, and I assume (but must confirm) that the same holds for dart2js. I think our overriding rules would be fine with the required change. One difficulty is with our assignability rules, as we allow assignment from supertypes to subtypes, which would be a problem for function types. However, it is all fixable.

---

Added this to the M4 milestone.

[gbracha]

The 0.32 draft spec addresses this issue.

---

Added Done label.

[nex3]

Is this supported by dart2js and the VM? If not, can we open tracking bugs for those two?

[gbracha]

See issue #9057 and issue #9058.

[nex3]

Neato :).