Honestly what I’ve wanted for quite some time is just reasonable default
parameter names. $0/$1… or any variation on index-based arguments is terrible
for comprehension, and I feel like I’m being lazy and hurting whoever has to
look at the code next every time I type out something like say <A [String:
String]?.map { $0 } instead of .map{ key, value in key }. If the Dictionary
type’s map function could define “key” and “value” as parameter types it would
go a long way in terms or readability, in my opinion.
The index-based shorthand is rough to skim if you’re not well versed in the
types your dealing with a a given time.
> 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<[email protected]>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<[email protected]>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
