Lasse R.H. Nielsen

I like `_` as a placeholder for a single implicit function parameter. The implicitness does mean that we have to implicitly *delimit* the function body. (That problem is independent of...

FWIW I have no problem using `_` as special marker *especially* if it is no longer usable as an actual parameter name. (I may have other issues, but that ain't...

See https://github.com/dart-lang/language/issues/8#issuecomment-522013489 for why undelimited "functions" are a problem.

I'll just chime in with another option: * Closures till require =>, but parameters can be omitted. Either just all of them, or possibly also individual ones, like `(x,,z)=>` *...

The "invent a name" has only really been defined to work for a single parameter. If we use the names of the type parameters in the context type, or use...

With my suggestion: `foo(=> $1 + 1)`. It's not pretty, but it works for any parameter list and it's consistent with records. (Consistently ugly, but consistent!)

> `var x = =>$1 + 1;` What is the function type of that expression even? There is no context type, so there is no hint what the implicit parameter...

I'd be fine with exhausting lists if we can show that any list of the input type is definitely covered by at least one case. I don't want list types...

The error messages says that it tries to make `T` be `A`, which is not a a subtype of `A`. The analyzer helpfully tells us that `A` is `A`. Not...

The reason `case B()` does not promote is that `B` is not a subtype of `A`. It's a subtype of `A`, but unrelated to `A`. The reason `B` is not...