Personally I also don't like the `$N` syntax. But I don't suport `.N`
syntax as it looks like the closure argument is tuple, and like we use
tuple's values in body. But we removed association between tuples and
function parameters in Swift.
First my thoughts were about `_1` `_2` syntax.
reversed = names.sort( { _0 > _1 } )
as `_` similar as unnamed variable/parameter like
let _ = something()
But I'm also not sure if it worth to change this
On 30.05.2016 19:44, Frédéric Blondiau via swift-evolution 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
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
