[Proposal] Shorthand Argument Renaming

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

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

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

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

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

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.

2 Likes

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

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

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>:

Sorry for continuing this old discussion...

$0... are here and will stay with us and think this naming scheme is perfectly fine.

But (even with many arguments against it, see below): I think code would look much "nicer" when there would be – in addition to that naming scheme – aliases for the two most used ones, namely $0 and $1, I would like to use:

  • this as alias for $0
  • that as alias for $1

Yes, many arguments against it:

  • syntax change just to have it look "nicer"
  • inventing two new keywords
  • idea comes maybe 5 years to late?

OK, maybe just forget it and sorry for disturbing, but... well...

it's fine. as other member put it recently: a lot has happened between then and now. the community has matured, views have changed.

another alternative to consider would be: values.0 values.1 or even values[0] values[1] to make it less magically looking. in the latter case values is not a normal array, just follows the similar subscript notion (values[variable] would be an error, so would be values.first / values.count, etc). why "values" - for compatibility with the others (newValue, oldValue).

Thanks.

A replacement of the existing naming scheme will certainly not happen, I think. I would be happy having nice aliases for the most used one. I have good experience with "this" and "that" in a stack oriented programming language where "these:n" means the n-th element of the stack – most times you only need "these:1" and "these:2" and just write "this" and "that" what makes for nice looking, but also very readable code. In the Swift case it would not be for stack elements, but I think it is also very nice:

… sort { this > that }

i see. what is that stack based language?

interestingly there is no problem in real world to understand that this:

y + 2*x + cos(z)

is "obviously" this, without nit-picking:

{ x, y, z in
	y + 2*x + cos(z)
}

Actually, no, please avoid resurrecting old threads. People who were interested in the conversation 5 years ago may well not be interested anymore, and it's not even possible to unsubscribe from receiving email notifications for those who originally participated on the mailing lists and not the forums. These threads really should be locked.

Moreover, the context surrounding any motivations or proposed solutions may be very different now than 5 years ago. Even if the context hasn't changed much, it's not as though anyone can jump back into a thread they read 5 years ago and pick up where they left off.

If you have thoughts related to a topic that's been discussed before, but where the discussion has died down, it is easy enough to link to the old thread from a new one. This affords you the opportunity (and places on you the responsibility) to put your thoughts into enough context that someone with fresh eyes can engage with the topic, rather than leaving your readers with the onus of viewing or reviewing past messages that may no longer be relevant.

Thanks.

10 Likes

good point. please also define what "old" is, so we can follow this rule.

is it possible to auto lock topics after certain time to have this rule enforced?

All values like on a stack (so "this" and "that" make a lot of sense sense since "that" is further away from the top of the stack than "this").

Good point. So if you would like to comment, please go to the new thread.

1 Like

A good rule of thumb is that any thread with an envelope icon next to the date of any of it's posts is too old to bump.

6 Likes

I don't think that's a valid argument. People shouldn't have to think in such low-level terms, naming should make sense on the level that you are programming and there $0 and $1 are equals.

Can folks stop posting to this thread please? Thanks.

8 Likes

Yes it is. Discourse has this as a built-in feature. I’m on another Discourse forum that uses it. But every time I’ve brought it up here the idea is met with a collective shrug.