[Proposal] Shorthand Argument Renaming


(Frédéric Blondiau) #1

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.


(Leonardo Pessoa) #2

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


(Haravikk) #3

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


(Vladimir) #4

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
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Frédéric Blondiau) #5

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 <me@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


(David Waite) #6

Not for or against a change in shorthand/defaulted names in general, but leading-dot in particular.

Leading dot already means something (access a static property/method of the expected type, including enum types). This usage has nothing to do with that existing behavior of the syntax other than being terse. Reusing syntax for wildly different behavior is also a recipe for confusion.

In addition, the dot syntax may make people think they are acting on a member of a type or tuple, while that is not currently the underlying behavior.

-DW

···

On May 30, 2016, at 12:44 PM, 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


(Erica Sadun) #7

I really don't see a pressing need to change this. Zero-based counting is used in Swift arrays. I don't think the $-prefix is either superior or inferior to alternatives such as # or %, and has precedent in unix shell programming. Swift closures allow you to easily introduce meaningful names by using a closure signature with a parameter clause.

-- E

···

On May 30, 2016, at 2:19 PM, Frédéric Blondiau via swift-evolution <swift-evolution@swift.org> wrote:

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.


(Chris Williams) #8

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<me@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


(Frédéric Blondiau) #9

This was the point : $ has precedent in unix shell programming with one-based counting, and zero-based counting is used in Swift. Replacing $n with #n helps on improving consistency of syntax in a small way (a focus of Swift 3), by removing this incoherence.

···

On 30 May 2016, at 23:17, Erica Sadun <erica@ericasadun.com> wrote:

On May 30, 2016, at 2:19 PM, Frédéric Blondiau via swift-evolution <swift-evolution@swift.org> wrote:

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.

I really don't see a pressing need to change this. Zero-based counting is used in Swift arrays. I don't think the $-prefix is either superior or inferior to alternatives such as # or %, and has precedent in unix shell programming. Swift closures allow you to easily introduce meaningful names by using a closure signature with a parameter clause.

-- E


(Thorsten Seitz) #10

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 }.

So, just write the latter.

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 map function does not impose names on the arguments of the literal closure. You can choose them freely.

-Thorsten

···

Am 31.05.2016 um 10:14 schrieb Chris Williams via swift-evolution <swift-evolution@swift.org>: