Steven G. Johnson

@ararslan, we could certainly implement `(_)` as a shorthand for the `identity` function, but I'm not sure it's worthwhile. It seems better to leave `_` as an r-value (i.e. not...

@rfourquet, this is totally orthogonal to the piping syntax (#20331); I'm not sure you think why the latter would affect this. We've been discussing a currying/partial-application shorthand for literally years...

I think it would be short-sighted to tie currying syntax to piping syntax. Currying (partial function application) is useful for lots of things beside piping.

I could imagine a "loose-binding" syntax like `_(...)`, e.g. `_(_.a > _.b)`. This would still be pretty terse, would be unambiguous and not restricted to certain precedence levels, is easy...

@bramtayl, possibly not. In general, I'm skeptical of the need for this kind of terse syntax beyond single function calls. And all the attempts to come up with a "loose...

@yurivish, in this PR, `_` only works in the *arguments* of a function. `_(arg1, arg2)` is currently not allowed. It could be added later, of course.

@yurivish, yes `map(_[3], arrays)` works as-is in this PR.

@andyferris, I think that if the binding of `_` were delimited by `|>`, it would be pretty unfortunate: * Currying is extremely useful outside of `|>`. Either you don't allow...

("Loose" binding for a selected set of operators like `+` could also be achieved on top of this PR by defining function-composition methods for them, analogous to what we did...

Grepping the Julia source code for `\w+ *->`, I'm finding what appears to be 100+ cases (at least) where this syntax could be used (i.e. single-argument anonymous functions that pass...