Steven G. Johnson

@bramtayl, that would mean `_ -> 1` would get turned into `x -> (x -> 1)`, for example, so I think we wouldn't want to apply this rule to every...

Updated to lower two-argument partial application to `Fix1` (#26708) or `Fix2` (#26436).

Interesting suggestion, @StefanKarpinski! Two disadvantages of that: 1. Although `f(x, _, _)` could be achieved by the proposed `f(x, ...)`, the latter syntax could not express `f(_, x, _)`. 2....

(I just noticed that `f(_...)` isn't lowered in a sensible way by the current PR. I could either change it to the proposed vararg syntax or just disallow it for...

It may also be the case that once this is merged, people find that they rarely need varargs capability, so that we don't need an abbreviated syntax for that.

One drawback of the `Fix2` lowering specialization, for 2-arg functions, is that it may inhibit optimizations for literal constant arguments. Most seriously, `_.x` is lowered to `Fix2{typeof(getproperty),Symbol}(getproperty, :x)`, which seems...

@StefanKarpinski, so `y + 3_` would expand to `x -> y + 3x`, but `y + sqrt(_)` would expand to `y + (x -> sqrt(x))` in your proposal? This is...

> No: rule 1 dictates that the expression expands to include sqrt(_) and rule 2 says keep going until you reach the argument part of function call syntax, which doesn’t...

Another problem with @StefanKarpinski's proposed semantics is that it is impossible for macro authors to process, since by the time you get to a macro (or to lowering), you have...

If you are so worried about multi-argument +, we could parse `_+y+z` as `(_+y)+z`. Problem solved. (However, this is slightly breaking.) Doing your transformation at parse time would be even...