Support shorthand argument names for closures

[erf]

I'd like to propose Shorthand Argument Names, like in the Swift language, so you can omit to explicit name arguments, but rather refer to them by $0, $1 etc. Which would result in less code and typing.

So instead of:

              children: list.map((p) => Thing(p)).toList(),

You could write:

              children: list.map(Thing($0)).toList(),

[eernstg]

Cf. similarities with #265.

[lrhn]

Or just write

  children: [for (var p in list) Thing(p)]

and avoid the closure entirely.
(You get a for (...in...) instead, so its still not remarkably short).

If we had constructor tear-offs, it would just be

  children: [...list.map(Thing)]

[erf]

@eernstg it is similar, but are you able to refer to multiple arguments? In Swift you can use $0 $1 $2

[eernstg]

No, #265 only supports 0 arguments or 1 argument, but maintains that a function literal can be recognized syntactically. If we use a mechanism that cannot be recognized as a function literal (because it's just a function body which could perfectly well parse as an expression) then we'd have to rely on the static typing before we could even make the choice of making it a function literal respectively an expression. But it's still tricky, e.g., would f($0) denote ($0) => f($0) or f(($0) => $0)? Again, this would be highly ambiguous, and I'm sure you could construct a situation where there is more than one interpretation that type checks. How do they avoid the ambiguity in Swift?

[lrhn]

Swift uses square brackets for map (dictionary) literals, [1: "foo", 2: "bar"], and the same for set literals, presumably distinguished from lists by context type. As such, { does not occur in expressions otherwise.

[eernstg]

How would that disambiguate list.map(Thing($0)).toList() without comparing types and context types for each subexpression?

[erf]

@eernstg i'm sorry, i think you lost me in that reasoning, i'm not that deep into language design ( or just not smart enough ), i just find that syntactic sugar helpful. please feel free to close this issue if you are a contributor and don't think this is relevant.

[eernstg]

@erf wrote:

i think you lost me

Sorry about that, the problem I was referring to is simply that we don't know how big a given function literal is, and there could be lots of possibilities: list.map(Thing($0)).toList() could mean any of the following:

list.map(Thing((x) => x)).toList()
list.map((x) =>Thing(x)).toList()
((x) => list.map(Thing(x))).toList()
(x) => list.map(Thing(x)).toList()

We could easily have a situation where more than one of those is not a type error (and an expression could be a lot bigger, so we could have many more possible interpretations), and even if there is exactly one interpretation which is not an error it isn't very good for the readability of the source code if you need to know the details of sub-expression typing in order to know how much of an expression is implicitly turned into a function literal.

@tatumizer wrote:

we just have to consider renaming it to $0 and adding support for N-arg functions

That would not be difficult.

[erf]

Ok, i'm closing now since it seem to be a duplicate of #265