I agree with the intent; I don’t especially like the dollar-sign syntax either, but I’m not a fan of this as an alternative either.
Considering this is a kind of compiler magic, what about using #0, #1 etc. instead? > On 30 May 2016, at 17:44, Frédéric Blondiau via swift-evolution > <swift-evolution@swift.org> wrote: > > Hello, > > I was thinking about this, and would like to get some feedback before making > my first proposal. > > Best regards, > > > Fred. > --- > > Shorthand Argument Renaming > > > Introduction > > Swift automatically provides shorthand argument names to inline closures > which cleverly allows us to write > > reversed = names.sort( { $0 > $1 } ) > > I would suggest to use another syntax, using these new “names” > > reversed = names.sort( { .0 > .1 } ) > > > Motivation > > The $n notation is generally used with positional parameters using one-based > numbering, $1 referring to argument 1; $2, to argument 2... with a special > meaning for $0 (could be the name of the function, or the full list of > parameters). > > This $n notation is often handy, but feels strange in Swift... like imported > from UNIX scripting (but here zero-based, anyway). > > > Proposed solution > > The .n notation is more Swift-like — as used to access Tuple members, for > example. > > > Detailed design > > Today, .0 or .1 (as any .n's) are refused by the compiler, as being not valid > floating point literals. > > I’m not a compiler expert, but eventually fetching this error inside a > closure body could easily be translated into accepting this new syntax. > > There can’t be conflict with other shorthands (like accessing static members > using dot notation) as members can’t consist of only digits characters. > > > Impact on existing code > > $n need to be rewritten .n > > > Alternatives considered > > Create a default argument named “arguments” (like “error” in catch, > “newValue” in setters or “oldValue” in a a didSet observer) accessed like a > Tuple > > reversed = names.sort( { arguments.0 > arguments.1 } ) > > but this is (of course) much less convenient. > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution