[Review] SE-0084: Allow trailing commas in parameter lists and tuples

        * What is your evaluation of the proposal?

Trailing commas is clearly very useful in the collections case. While that case is more common than functions and tuples, I don't see any reason that collections should be treated as a special case. Why should some comma-separated lists allow trailing commas and some not?

This seems a reasonable move towards consistency and is useful in some cases while not harmful in others. When in doubt, I'd rather broad rules ("trailing commas are allowed in comma-separated lists") rather than special cases. This improves teachability.

If one look purely at commas, the inconsistency may be hard to explain, but if one include the enclosing characters there are clear rules:

- within square brackets: trailing comma allowed
- within parenthesis: trailing comma not allowed
- within angle bracket: trailing comma not allowed

Weird, I do not recall anyone mentioning generics in the original trailing comma thread.

Dany

···

On May 10, 2016, at 4:57 PM, Rob Napier via swift-evolution <swift-evolution@swift.org> wrote:

On Tue, May 10, 2016 at 2:53 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:

It also improves diffs when functions pick up new parameters, particularly ones with default values. This is particularly common (and expected) in constructors. That's valuable.

        * Is the problem being addressed significant enough to warrant a change to Swift?

As a language rule simplification, I believe it's worth a change if it doesn't introduce problematic corner cases. The fact that it improves diffs is no less valuable for functions than it is for collections.

        * Does this proposal fit well with the feel and direction of Swift?

Yes; it definitely feels Swifty in the same way that it does for collections. There's no reason for Swift to treat them differently.

        * If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

I've seen this in Perl, Python, and Go. Basically every language I've used that allows trailing commas in collections also allows them in function calls. In Go, the trailing comma is mandatory in some cases. This has been nice for consistency.

        * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

Quick reading.

-Rob

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

This objection is coming up quite often and I don't really see the difference between trailing commas in collections (legal in Swift)

let listenerKeys: NSDictionary = [
    AVFormatIDKey: NSNumber(unsignedInt: kAudioFormatAppleLossless),
    AVSampleRateKey: 44100.0,
    AVNumberOfChannelsKey: 1,
    AVEncoderAudioQualityKey: NSNumber(int: Int32(AVAudioQuality.Max.rawValue)),
]

And trailing commas in parameter lists (not yet allowed in Swift):

public convenience init(
    _ w: CGFloat,
    _ h: CGFloat,
    position: CGPoint = .zero,
    backgroundColor: UIColor = UIColor.whiteColor(),
    translucency alpha: CGFloat = 1.0,
    borderWidth: CGFloat = 0.0,
    borderColor: UIColor = UIColor.blackColor(),
    cornerRadius: CGFloat = 0.0, // this is currently illegal
    ){
    ...
}

Neither example reads to me as if an element was removed by mistake. Both greatly enhance programming flexibility. Both allow the final comma to be omitted and/or the elements to be re-ordered.

To summarize the complaints to date:

* It make code read like errors
* Arrays and dictionaries are different "things" than parameters and tuples; They are structurally different
* Parameter lists should always be of fixed size at deployment time; Once a signature is fixed and consumed, it's difficult to change

To which I reply:

* Well structured code needn't read like an error. The examples above show an in-house style that allows final commas. Your in-house style may differ and a linter can catch these issues.
* Both collections and signatures are syntactically similar in layout even if they are semantically different in use. In Swift, complex method signatures with defaulted arguments like the example shown are not uncommon. Do not limit your thinking to single line lists of (x: T, y: U, z: V) signatures.
* Parameter lists and function signatures, like collections, can evolve, especially when using defaulted parameters, even when they are consumed at multiple points.

-- E

···

On May 11, 2016, at 8:01 AM, Ricardo Parada via swift-evolution <swift-evolution@swift.org> wrote:

On May 10, 2016, at 2:53 PM, Chris Lattner <clattner@apple.com <mailto:clattner@apple.com>> wrote:

Hello Swift community,

The review of "SE-0084: Allow trailing commas in parameter lists and tuples" begins now and runs through May 16. The proposal is available here:

  https://github.com/apple/swift-evolution/blob/master/proposals/0084-trailing-commas.md

  * What is your evaluation of the proposal?

-1

I don’t like the proposal. I understand the flexibility it gives to rearranging elements but to someone reading the code it looks like an element was removed by mistake.

Would you then recommend removing trailing comma support for collections on the same principle?

-- E

···

On May 11, 2016, at 9:08 AM, Evan Maloney via swift-evolution <swift-evolution@swift.org> wrote:

It feels wrong to allow garbage syntax lying around in one's code simply for the sake of occasional convenience.

In response to observations that tuples and function arguments are somehow different from collection literals because they generally have fixed arity, I'll note that we have an very prominent variadic function in the standard library, "print", and that adding or removing values to a "print" is a very common and natural thing to do.

-Joe

···

On May 11, 2016, at 9:47 AM, Joe Groff via swift-evolution <swift-evolution@swift.org> wrote:

On May 10, 2016, at 11:53 AM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:

Hello Swift community,

The review of "SE-0084: Allow trailing commas in parameter lists and tuples" begins now and runs through May 16. The proposal is available here:

  https://github.com/apple/swift-evolution/blob/master/proposals/0084-trailing-commas.md

Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at

  https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the review manager.

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and contribute to the direction of Swift. When writing your review, here are some questions you might want to answer in your review:

  * What is your evaluation of the proposal?
  * Is the problem being addressed significant enough to warrant a change to Swift?
  * Does this proposal fit well with the feel and direction of Swift?
  * If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
  * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

More information about the Swift evolution process is available at

  https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Chris Lattner
Review Manager

+1 from me. We should be consistent in either accepting or rejecting trailing commas everywhere we have comma-delimited syntax. I'm in favor of accepting it, since it's popular in languages where it's supported to enable a minimal-diff style, so that changes to code don't impact neighboring lines for purely syntactic reasons. If you add an argument to a function, without trailing comma support, a comma has to be added to dirty the previous line:

  --- a.swift
  +++ a.swift
   foo(
     x: 0,
  - y: 1
  + y: 1,
  + z: 2
   )

Trailing commas avoid this:

  --- a.swift
  +++ a.swift
   foo(
     x: 0,
     y: 1,
  + z: 2,
   )

In languages that don't support trailing commas, many users resort to the abomination of leading-comma style, strangely popular in Haskell and related languages:
  
  --- a.swift
  +++ a.swift
   foo( x: 0
      , y: 1
  + , z: 2
      )

I think the trailing-comma syntax jives much better with Swift style.

I think that, to me, the ability to allow trailing commas is linked with the ability to arbitrarily reorder defaulted parameters. If we retain arbitrary reordering of defaults (which I like and have taken advantage of), then we should allow trailing commas as well. Both of these features together help make quick playground prototyping and experimentation easy and painless.

l8r
Sean

···

On May 11, 2016, at 10:09 AM, Erica Sadun via swift-evolution <swift-evolution@swift.org> wrote:

On May 11, 2016, at 8:01 AM, Ricardo Parada via swift-evolution <swift-evolution@swift.org> wrote:

On May 10, 2016, at 2:53 PM, Chris Lattner <clattner@apple.com> wrote:

Hello Swift community,

The review of "SE-0084: Allow trailing commas in parameter lists and tuples" begins now and runs through May 16. The proposal is available here:

  https://github.com/apple/swift-evolution/blob/master/proposals/0084-trailing-commas.md

  * What is your evaluation of the proposal?

-1

I don’t like the proposal. I understand the flexibility it gives to rearranging elements but to someone reading the code it looks like an element was removed by mistake.

This objection is coming up quite often and I don't really see the difference between trailing commas in collections (legal in Swift)

let listenerKeys: NSDictionary = [
    AVFormatIDKey: NSNumber(unsignedInt: kAudioFormatAppleLossless),
    AVSampleRateKey: 44100.0,
    AVNumberOfChannelsKey: 1,
    AVEncoderAudioQualityKey: NSNumber(int: Int32(AVAudioQuality.Max.rawValue)),
]

And trailing commas in parameter lists (not yet allowed in Swift):

public convenience init(
    _ w: CGFloat,
    _ h: CGFloat,
    position: CGPoint = .zero,
    backgroundColor: UIColor = UIColor.whiteColor(),
    translucency alpha: CGFloat = 1.0,
    borderWidth: CGFloat = 0.0,
    borderColor: UIColor = UIColor.blackColor(),
    cornerRadius: CGFloat = 0.0, // this is currently illegal
    ){
    ...
}

Neither example reads to me as if an element was removed by mistake. Both greatly enhance programming flexibility. Both allow the final comma to be omitted and/or the elements to be re-ordered.

To summarize the complaints to date:

* It make code read like errors
* Arrays and dictionaries are different "things" than parameters and tuples; They are structurally different
* Parameter lists should always be of fixed size at deployment time; Once a signature is fixed and consumed, it's difficult to change

To which I reply:

* Well structured code needn't read like an error. The examples above show an in-house style that allows final commas. Your in-house style may differ and a linter can catch these issues.
* Both collections and signatures are syntactically similar in layout even if they are semantically different in use. In Swift, complex method signatures with defaulted arguments like the example shown are not uncommon. Do not limit your thinking to single line lists of (x: T, y: U, z: V) signatures.
* Parameter lists and function signatures, like collections, can evolve, especially when using defaulted parameters, even when they are consumed at multiple points.

-- E
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

It feels wrong to allow garbage syntax lying around in one's code simply for the sake of occasional convenience.

Would you then recommend removing trailing comma support for collections on the same principle?

Yes.

To me, this reads like a solution in search of a problem, and the arbitrary
syntactical freedom—and IMO, ugliness—that would be allowed by it outweighs
the benefit of not having to type a comma occasionally. We shouldn't just
loosen the syntax of a language arbitrarily because tools can produce
linter warnings or auto-correct them; if we use that as our determining
factor, where do we draw the line?

Once a function signature evolves, you typically have to change all of the
call sites (excepting arguments with default values), which will be a
bigger task than inserting a comma anyway. And if you only have to change
the function definition (if it's a default argument), is the extra comma
you have to add that big of a problem? How often in the process of writing
code is someone going to re-order default arguments that this would be a
significant benefit?

Since you alluded to teaching earlier as a scenario to consider, in my
(anecdotal, of course) experience teaching CS, I've never run into a time
where a student was confused by the inability to put a trailing comma in an
argument list or where it was more than a trivial inconvenience to have to
add one later, but I *can* recall times where they stumbled over trailing
commas when they were present ("does it have a different meaning?" "is
there an empty item in this list?", etc.). That harkens back to concerns
that trailing commas make code look like there's something "missing" or
"left out."

Of course, the argument could be made that I personally would be mostly
unaffected by this change—I don't use trailing commas now and this proposal
wouldn't force me to start. So why do I care? I feel that changes that
would loosen the language syntax should have to meet an extremely high bar
other than allowing for personal style preference or convenience.
Consistency is a good goal, but if that was the argument being made, I'd
argue the opposite direction—commas should be uniformly treated as
separators, not terminators, and should not be allowed in a terminating
position in collection literals either, even despite the fact that I think
there is more of a case to be made to allow them there vs. here.

···

On Wed, May 11, 2016 at 8:09 AM Erica Sadun via swift-evolution < swift-evolution@swift.org> wrote:

To summarize the complaints to date:

* It make code read like errors
* Arrays and dictionaries are different "things" than parameters and
tuples; They are structurally different
* Parameter lists should always be of fixed size at deployment time; Once
a signature is fixed and consumed, it's difficult to change

To which I reply:

* Well structured code needn't read like an error. The examples above show
an in-house style that allows final commas. Your in-house style may differ
and a linter can catch these issues.
* Both collections and signatures are syntactically similar in layout even
if they are semantically different in use. In Swift, complex method
signatures with defaulted arguments like the example shown are not
uncommon. Do not limit your thinking to single line lists of (x: T, y: U,
z: V) signatures.
* Parameter lists and function signatures, like collections, can evolve,
especially when using defaulted parameters, even when they are consumed at
multiple points.

To which I reply:

* Well structured code needn't read like an error. The examples above show
an in-house style that allows final commas. Your in-house style may differ
and a linter can catch these issues.

Will not discuss about taste. Someone likes commas, someone not. Not important.

* Both collections and signatures are syntactically similar in layout even
if they are semantically different in use. In Swift, complex method
signatures with defaulted arguments like the example shown are not
uncommon. Do not limit your thinking to single line lists of (x: T, y: U,
z: V) signatures.
* Parameter lists and function signatures, like collections, can evolve,
especially when using defaulted parameters, even when they are consumed at
multiple points.

Can't agree. For me the main point is *they are semantically different in use*, this is why I like trailing commas in array/dict and don't like in signatures. For me array/dict - is "data", parameter list - is "code".

Personally I support the idea of dropping comma in array/dict to allow line break separate elements(like operations in Swift code):
let a = [
  10
  20
  30
  40
  ]
  
let d = [
  10 : "a"
  20 : "b"
  30 : "c"
  40 : "d"
  ]
  
but I don't know if I'd support the same for parameter list/tuples, probably will not support.

···

On 11.05.2016 18:09, Erica Sadun via swift-evolution wrote:

In this case (if this is a such good feature) IMO we should think about making the trailing commas *required*. In this way we will be consistent in either do we have trailing commas in Swift or don't. Otherwise we'll have a zoo in our sources/projects.

I don't think we need to have the same rules for commas "everywhere we have comma-delimited syntax".

···

On 11.05.2016 19:47, Joe Groff via swift-evolution wrote:

+1 from me. We should be consistent in either accepting or rejecting
trailing commas everywhere we have comma-delimited syntax. I'm in favor of
accepting it, since it's popular in languages where it's supported to
enable a minimal-diff style, so that changes to code don't impact
neighboring lines for purely syntactic reasons. If you add an argument to a
function, without trailing comma support, a comma has to be added to dirty
the previous line:

My apologies... I did not know that trailing commas were already legal. Thanks for pointing that out. Nevertheless I don't think I would have supported that.

I also understand that the trailing comma may help a "git diff" look better and simpler.

The trailing comma still bothers me though because it looks like somebody forgot to add something or as if something got deleted by mistake.

I would support the trailing comma so that the language is consistent but I don't think I would personally use it.

···

On May 11, 2016, at 11:09 AM, Erica Sadun <erica@ericasadun.com> wrote:

On May 11, 2016, at 8:01 AM, Ricardo Parada via swift-evolution <swift-evolution@swift.org> wrote:
On May 10, 2016, at 2:53 PM, Chris Lattner <clattner@apple.com> wrote:

Hello Swift community,

The review of "SE-0084: Allow trailing commas in parameter lists and tuples" begins now and runs through May 16. The proposal is available here:

  https://github.com/apple/swift-evolution/blob/master/proposals/0084-trailing-commas.md

  * What is your evaluation of the proposal?

-1

I don’t like the proposal. I understand the flexibility it gives to rearranging elements but to someone reading the code it looks like an element was removed by mistake.

This objection is coming up quite often and I don't really see the difference between trailing commas in collections (legal in Swift)

let listenerKeys: NSDictionary = [
    AVFormatIDKey: NSNumber(unsignedInt: kAudioFormatAppleLossless),
    AVSampleRateKey: 44100.0,
    AVNumberOfChannelsKey: 1,
    AVEncoderAudioQualityKey: NSNumber(int: Int32(AVAudioQuality.Max.rawValue)),
]

And trailing commas in parameter lists (not yet allowed in Swift):

public convenience init(
    _ w: CGFloat,
    _ h: CGFloat,
    position: CGPoint = .zero,
    backgroundColor: UIColor = UIColor.whiteColor(),
    translucency alpha: CGFloat = 1.0,
    borderWidth: CGFloat = 0.0,
    borderColor: UIColor = UIColor.blackColor(),
    cornerRadius: CGFloat = 0.0, // this is currently illegal
    ){
    ...
}

Neither example reads to me as if an element was removed by mistake. Both greatly enhance programming flexibility. Both allow the final comma to be omitted and/or the elements to be re-ordered.

To summarize the complaints to date:

* It make code read like errors
* Arrays and dictionaries are different "things" than parameters and tuples; They are structurally different
* Parameter lists should always be of fixed size at deployment time; Once a signature is fixed and consumed, it's difficult to change

To which I reply:

* Well structured code needn't read like an error. The examples above show an in-house style that allows final commas. Your in-house style may differ and a linter can catch these issues.
* Both collections and signatures are syntactically similar in layout even if they are semantically different in use. In Swift, complex method signatures with defaulted arguments like the example shown are not uncommon. Do not limit your thinking to single line lists of (x: T, y: U, z: V) signatures.
* Parameter lists and function signatures, like collections, can evolve, especially when using defaulted parameters, even when they are consumed at multiple points.

-- E

I +1 the proposal. If it doesn’t make the compiler more complicated, and its a purely opt-in feature for writers, then I don’t why it couldn’t literally extend to everywhere there’s a comma-separated list as a general rule.

···

On 11 May 2016, at 6:57 AM, Rob Napier via swift-evolution <swift-evolution@swift.org> wrote:

On Tue, May 10, 2016 at 2:53 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

        * What is your evaluation of the proposal?

Trailing commas is clearly very useful in the collections case. While that case is more common than functions and tuples, I don't see any reason that collections should be treated as a special case. Why should some comma-separated lists allow trailing commas and some not?

This seems a reasonable move towards consistency and is useful in some cases while not harmful in others. When in doubt, I'd rather broad rules ("trailing commas are allowed in comma-separated lists") rather than special cases. This improves teachability.

It also improves diffs when functions pick up new parameters, particularly ones with default values. This is particularly common (and expected) in constructors. That's valuable.

        * Is the problem being addressed significant enough to warrant a change to Swift?

As a language rule simplification, I believe it's worth a change if it doesn't introduce problematic corner cases. The fact that it improves diffs is no less valuable for functions than it is for collections.

        * Does this proposal fit well with the feel and direction of Swift?

Yes; it definitely feels Swifty in the same way that it does for collections. There's no reason for Swift to treat them differently.

        * If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

I've seen this in Perl, Python, and Go. Basically every language I've used that allows trailing commas in collections also allows them in function calls. In Go, the trailing comma is mandatory in some cases. This has been nice for consistency.

        * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

Quick reading.

-Rob

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

-1 - for ever

Hello Swift community,

The review of "SE-0084: Allow trailing commas in parameter lists and tuples" begins now and runs through May 16. The proposal is available here:

  https://github.com/apple/swift-evolution/blob/master/proposals/0084-trailing-commas.md

Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at

  https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the review manager.

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and contribute to the direction of Swift. When writing your review, here are some questions you might want to answer in your review:

  * What is your evaluation of the proposal?
  * Is the problem being addressed significant enough to warrant a change to Swift?
  * Does this proposal fit well with the feel and direction of Swift?
  * If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
  * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

More information about the Swift evolution process is available at

  https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Chris Lattner
Review Manager

+1 from me. We should be consistent in either accepting or rejecting trailing commas everywhere we have comma-delimited syntax. I'm in favor of accepting it, since it's popular in languages where it's supported to enable a minimal-diff style, so that changes to code don't impact neighboring lines for purely syntactic reasons. If you add an argument to a function, without trailing comma support, a comma has to be added to dirty the previous line:

  --- a.swift
  +++ a.swift
   foo(
     x: 0,
  - y: 1
  + y: 1,
  + z: 2
   )

Trailing commas avoid this:

  --- a.swift
  +++ a.swift
   foo(
     x: 0,
     y: 1,
  + z: 2,
   )

In languages that don't support trailing commas, many users resort to the abomination of leading-comma style, strangely popular in Haskell and related languages:

I am not sure I understand where the “abomination” lies in using leading-comma style… but I will try to see it.

  --- a.swift
  +++ a.swift
   foo( x: 0
      , y: 1
  + , z: 2
      )

I think the trailing-comma syntax jives much better with Swift style.

If commas are to be construed as elegantly but meaninglessly dropped little crumbs, then one can see why it might not matter where they go, or how many there are, which as well as begging the question of allowing them at the end, should equally prompt the question of completely removing them altogether. And if having extras is just great anticipation on future needs, should we think about considering the following lines as all equivalent

let v0 = (1,
          2,
          3)
let v1 = (1,
          2,
          3,
         )
let v2 = (, // just in case I want to add something at the front later?!
          1,
          2,
          3,)
let v3 = (1,
          2,

···

On May 11, 2016, at 6:47 PM, Joe Groff via swift-evolution <swift-evolution@swift.org> wrote:

On May 10, 2016, at 11:53 AM, Chris Lattner via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

          ,
          3,
         ) // just in case I want to add something in the middle or front later
let v4 = (1,,
          2,,
          3,,) // lets be really good programmer, in case it doubles in length

Aside from the good-anticipation interpretation of trailing commas, there is also the thinking-interuptus line of interpretation:

  this and
  that and

standing for: now hold your breath, I am not done.. or maybe I lost my train of thoughts so I am actually done… who knows.. read the next line to figure that out.

As I recall there is an ongoing debate about long string literal… Perhaps this line of thinking can help there too?!! Swift would become very unique and progressive with something like:

let var = this is a long string literal” // notice my continuation quote at the end
     which I am continuing to the” // notice how I am letting people know that, like my parameter list,
     next line and perhaps even” // my string may not be quite finished yet
     to the next one and even” // …

Like in the convenient case of a trailing comma in a parameter list, I added a last quote character so that I can add another string later, without having to resort to the cliche notion of a leading quote. and like with trailing commas, it is just a placeholder because my string is really finished for now!

Another convenient area where this reasoning could potentially be applied might be logical expressions!!! The ability to anticipate on future needs to change a logical expression might also be neat there by allowing expressions like:

if (cond1 &&
      cond2 &&) {
}

which floats a lot than the overly tight:

if (cond1
      && cond2) {
}

I think I’m convinced… it is such a powerful concept it should probably extend to the english language at large and

Cheers
LM/
[just in case, I hope everyone has seen the tongue-in-cheeks tone ;-) ]

PS: can they actually be removed EVERYWHERE instead?!

-Joe
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

I agree that the trailing comma offers its best support for situations that express variadic properties. I propose that all three of the following scenarios share this nature:
At call sites with variadic arguments
At call sites with defaulted arguments
At definition sites with large complex argument lists or tuple members
It's slightly easier to make the case for call sites, the first two of these uses, as they exactly mirror the way collections parse members. Supporting the third style of trailing commas requires the consideration of real world modern Swift.

Allowing cut and paste or commenting of entire parameter lines means simple changes do not ripple out to affect other lines. In this, trailing commas serve programmer intent and limit the effect in diff comparisons. As Joe pointed out in one of his responses on this thread, one edit becomes one diff, without extra housekeeping for other affected lines. When considered together, I do believe the use cases for these scenarios are common enough to be considered something other than a "special case".

Given that SE-0060 is accepted, the third case is narrowed but should not be ignored. Reordering and commenting out lines during prototyping, working in playgrounds, and scripting is still common. Also, a reorder or comment when trailing commas are permitted ensures that such changes are single-point edits.

As Brent points out in his review, "I was skeptical of this until a week or two ago, when I had some code where I ended up commenting out certain parameters." Trailing commas, although a minor feature in a major language, still serves the developer and supports the overall philosophy of Swift, which is as you have pointed out multiple times, an opinionated language.

-- E

···

On May 10, 2016, at 2:58 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:

On May 10, 2016, at 12:36 PM, Tony Allevato <allevato@google.com <mailto:allevato@google.com>> wrote:

Likewise for function calls; I would argue that if a function call/definition's parameter list is likely to grow so much and/or so frequently that a trailing comma provides significant savings, that's a code smell that should encourage the author to redesign the function.

FWIW, I personally agree with this observation.

Parameter lists and tuples are also structurally different than collections. Parameter lists also have labels, and (depending on how the ‘disable reordering default arguments’ decision goes) parameters may not be added and reordered arbitrarily. Tuples are different because adding a member will often break all the code downstream because it changes the type of the value. This is different than array and dictionary literals.

The only “collection like” aspect I can think of is for variadic parameter lists, but I don’t think they’re common enough to provide a special case for.

You’re arguing that you want to read Swift code written like this?

-Chris

···

On May 11, 2016, at 9:47 AM, Joe Groff <jgroff@apple.com> wrote:

+1 from me. We should be consistent in either accepting or rejecting trailing commas everywhere we have comma-delimited syntax. I'm in favor of accepting it, since it's popular in languages where it's supported to enable a minimal-diff style, so that changes to code don't impact neighboring lines for purely syntactic reasons. If you add an argument to a function, without trailing comma support, a comma has to be added to dirty the previous line:

  --- a.swift
  +++ a.swift
   foo(
     x: 0,
  - y: 1
  + y: 1,
  + z: 2
   )

Trailing commas avoid this:

  --- a.swift
  +++ a.swift
   foo(
     x: 0,
     y: 1,
  + z: 2,
   )

I really don’t like that proposal too.

While I can understand why it may be useful for list, I find it very confusing to allow it in function declaration.
The motivation do not apply here. You can’t simply remove a parameter or reorder that without breaking all code that use that function (even function with default parameter as the parameter may be explicitly defined at invocation site).

Even in other places (list, enum, …), I think the kind of refactoring describe in the motivation is not something that is common enough to introduce that kind of syntax change.

And the fact that no alternative was investigated (like allowing new line as separator) make me think this proposal is not complete and shouldn’t be accepted as is anyway.

Jean-Daniel

···

Le 14 mai 2016 à 21:25, Kenny Leung via swift-evolution <swift-evolution@swift.org> a écrit :

I am against this proposal.

- I think it makes the code look ugly and incomplete when there is a trailing comma
- I much prefer the counter-proposal which would allow newline to be the separator for items in a list.
   - in general, it’s much better when you can remove something from your code rather than add something to it
   - this proposal serves the same purpose as allowing the trailing comma

-Kenny

On May 10, 2016, at 11:53 AM, Chris Lattner <clattner@apple.com> wrote:

Hello Swift community,

The review of "SE-0084: Allow trailing commas in parameter lists and tuples" begins now and runs through May 16. The proposal is available here:

  https://github.com/apple/swift-evolution/blob/master/proposals/0084-trailing-commas.md

Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at

  https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the review manager.

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and contribute to the direction of Swift. When writing your review, here are some questions you might want to answer in your review:

  * What is your evaluation of the proposal?
  * Is the problem being addressed significant enough to warrant a change to Swift?
  * Does this proposal fit well with the feel and direction of Swift?
  * If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
  * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

More information about the Swift evolution process is available at

  https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Chris Lattner
Review Manager

_______________________________________________
swift-evolution-announce mailing list
swift-evolution-announce@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution-announce

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

While I am a -1 on the proposal as written, I also have no objection to allowing newlines in place of commas for such lists to support the use-case for which people want this proposal.

···

On May 14, 2016, at 3:25 PM, Kenny Leung via swift-evolution <swift-evolution@swift.org> wrote:

I am against this proposal.

- I think it makes the code look ugly and incomplete when there is a trailing comma
- I much prefer the counter-proposal which would allow newline to be the separator for items in a list.
   - in general, it’s much better when you can remove something from your code rather than add something to it
   - this proposal serves the same purpose as allowing the trailing comma

-Kenny

On May 10, 2016, at 11:53 AM, Chris Lattner <clattner@apple.com> wrote:

Hello Swift community,

The review of "SE-0084: Allow trailing commas in parameter lists and tuples" begins now and runs through May 16. The proposal is available here:

  https://github.com/apple/swift-evolution/blob/master/proposals/0084-trailing-commas.md

Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at

  https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the review manager.

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and contribute to the direction of Swift. When writing your review, here are some questions you might want to answer in your review:

  * What is your evaluation of the proposal?
  * Is the problem being addressed significant enough to warrant a change to Swift?
  * Does this proposal fit well with the feel and direction of Swift?
  * If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
  * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

More information about the Swift evolution process is available at

  https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Chris Lattner
Review Manager

_______________________________________________
swift-evolution-announce mailing list
swift-evolution-announce@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution-announce

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

        * What is your evaluation of the proposal?

Trailing commas is clearly very useful in the collections case. While that case is more common than functions and tuples, I don't see any reason that collections should be treated as a special case. Why should some comma-separated lists allow trailing commas and some not?

This seems a reasonable move towards consistency and is useful in some cases while not harmful in others. When in doubt, I'd rather broad rules ("trailing commas are allowed in comma-separated lists") rather than special cases. This improves teachability.

If one look purely at commas, the inconsistency may be hard to explain, but if one include the enclosing characters there are clear rules:

- within square brackets: trailing comma allowed
- within parenthesis: trailing comma not allowed
- within angle bracket: trailing comma not allowed

- within compound “conditions” (of while, if, guard): trailing comma not allowed

-Chris

···

On May 10, 2016, at 5:51 PM, Dany St-Amant via swift-evolution <swift-evolution@swift.org> wrote:
On May 10, 2016, at 4:57 PM, Rob Napier via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On Tue, May 10, 2016 at 2:53 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Weird, I do not recall anyone mentioning generics in the original trailing comma thread.

Dany

It also improves diffs when functions pick up new parameters, particularly ones with default values. This is particularly common (and expected) in constructors. That's valuable.

        * Is the problem being addressed significant enough to warrant a change to Swift?

As a language rule simplification, I believe it's worth a change if it doesn't introduce problematic corner cases. The fact that it improves diffs is no less valuable for functions than it is for collections.

        * Does this proposal fit well with the feel and direction of Swift?

Yes; it definitely feels Swifty in the same way that it does for collections. There's no reason for Swift to treat them differently.

        * If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

I've seen this in Perl, Python, and Go. Basically every language I've used that allows trailing commas in collections also allows them in function calls. In Go, the trailing comma is mandatory in some cases. This has been nice for consistency.

        * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

Quick reading.

-Rob

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto: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

We've generally shied away from legislating style; see our rationale behind not requiring `self.` for an example:

https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160104/005478.html

In languages where trailing commas are pervasively allowed, such as Perl, Python, Ruby, and modern Javascript, I haven't seen any indication that this is a major problem. Less blood has definitely been shed over it than over bracing style and other style wars.

-Joe

···

On May 11, 2016, at 10:14 AM, Vladimir.S <svabox@gmail.com> wrote:

In this case (if this is a such good feature) IMO we should think about making the trailing commas *required*. In this way we will be consistent in either do we have trailing commas in Swift or don't. Otherwise we'll have a zoo in our sources/projects.

I don't think we need to have the same rules for commas "everywhere we have comma-delimited syntax".

Dropping the commas looks good and doesn't look like someone made a mistake. I don't know what other implications / complications dropping the commas would have but I like it.

···

On May 11, 2016, at 12:20 PM, Vladimir.S via swift-evolution <swift-evolution@swift.org> wrote:

Personally I support the idea of dropping comma in array/dict to allow line break separate elements(like operations in Swift code):
let a = [
   10
   20
   30
   40
   ]
   
let d = [
   10 : "a"
   20 : "b"
   30 : "c"
   40 : "d"
   ]

I’m going to propose the keyword #litter as an alias for , so I can throw garbage syntax into my code more effectively seven letters at time :P

I think this is just a choice of taste, and this is offering an additional choice. You don’t have to agree with it, you don’t have to make use of it, you don’t even have to know it’s there.

We’ve all seen and written messy code, and it wasn’t due to the punctuation. There are much more powerful weapons at hand for that.

···

On 12 May 2016, at 1:25 AM, Evan Maloney via swift-evolution <swift-evolution@swift.org> wrote:

It feels wrong to allow garbage syntax lying around in one's code simply for the sake of occasional convenience.

Would you then recommend removing trailing comma support for collections on the same principle?

Yes.

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution