In any case, it remains a major hole in closure usage. Given multiple arguments using shorthand argument names, the compiler requires the last argument to be used.
Examples from @Joe_Groff "These should all be valid":
let _: () -> () = {}
let _: (Int) -> () = {}
let _: (Int, Int) -> Int = { 5 }
let _: (Int, Int) -> Int = { $0 }
let _: (Int, Int) -> Int = { $1 }
The current state of affairs also kills code completion until you type the last argument. Sometimes you have to type the last argument on it's own line just so you can get code completion to work temporarily.
So there are two usability problems, (1) the general limitation and (2) code completion.
Fixing this would be non-breaking. Existing code would just work and new code could take advantage of the improvement.
IIRC, there was a thread a few months back where @Douglas_Gregor expressed optimism that some of his work on result builders over the past couple years has left the type inference system better prepared to handle this, so it may be an easier fix now than in the past. Would love to see this restriction lifted!
I sure would love to see this problem fixed. I’ve gone so far as to design APIs around it, making the more-frequently-used argument to closures appear second so that API clients can use only $1 without errors.
Before this sinks to the bottom of the evolutionary pond could a member of the core team provide some indication if or when this might be resolved. Thank you.
I think this would continue to work—I was unable to track down the specific post, but I believe the first example is the 'correct' one (since the closure expression ostensibly has type ((Int, Int)) -> Int, which is the element type of the array.
That the second version is supported is, IIRC, a compromise made around the removal of equivalence between the types (T1, ..., Tn) -> U and ((T1, ..., Tn)) -> U. From the archives:
So in the first example, the closure expression is inferred to have type ((Int, Int)) -> Int which matches the type of the argument. In the second example, the closure expression is inferred to have type (Int, Int) -> Int and is then converted to match the expected argument type. I don't see anything about this proposal that would break that system.
It's been one year since this thread was opened, to lift the limitation that closures must use the last shorthand argument. It seems most are in agreement it needs to be done. What are next steps?