Thanks for your feedback.
I personally never found that this “$n” convention was “Swift-like”... but it’s
true that a “$n” is easier to spot than a “.n”, and I got used to also.
However, I realised how much this was disturbing for newcomers, when explaining
closure shorthand argument names to a classroom of computer science students
(aged 21) discovering Swift.
The feedback some gave me, during the course, was quite surprisingly strong and
negative about this “$n” convention. This convinced me to write this proposal :
for newcomers, the “$n” zero-based is something wrong.
I understand that association between tuples and function parameters in Swift
is to be removed, but, in this case, as we have no parameters at all, I thought
this was a distinct enough situation.
As suggested, considering this is a kind of compiler magic, using #0, #1
instead, may indeed be a better alternative.
I’m still waiting some feedback before writing an official proposal.
> On 30 May 2016, at 19:12, Leonardo Pessoa <m...@lmpessoa.com> wrote:
>
> Fréderic, the idea and reasoning are good and do make sense but I'm
> not 100% go on this. When I started using this syntax I felt like I
> was back in PHP but once I got used it's ok. I don't see anything
> wrong that justifies the change in syntax. Looking at your examples I
> even think it's easier to spot "$n" in my code than ".n".
>
>
> On 30 May 2016 at 13:44, Frédéric Blondiau <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
