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

Evolution Announcements
41

IMO language will be consistent (regarding trailing comma) if we extend the proposal to *any comma-separated list* in Swift.. like list of generic types <T,U,V,>.
So, I'd understand if Swift will allow(or better - *require*) trailing comma in *any* such list. Or just for array/dict. But not for some piece of code(func params, tuples), but not for other(list of generics or other)

And I don't accept the problem with diffs - yes, diff will show you not just new element is added, but also that element that was last is not last anymore.
Also, often closed `)` is placed on the same line with last parameter:
func myFunc(a: Int,
  b: String,
  c: Int,) {
}
so after we add `d` parameter:
func myFunc(a: Int,
  b: String,
  c: Int,
  d: String) {
}

the diff will show not only new `d` declaration, but also changes to `c` line even with trailing comma.

IMO when I write function(code), I usually don't expect it will have more arguments. When I write array/dict initialization(data), I usually expect to add more items to it.

So I'm strongly -1 on this proposal in any case. At least we should extend it to allow trailing comma in any list. And I then (if this is so pretty feature) prefer Swift to require that trailing comma in list. This will be consistent and strict.

···

On 12.05.2016 5:28, Ricardo Parada via swift-evolution wrote:

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

42

I'm +1 on allowing either trailing commas *or* a line-break instead of
where a comma is expected.

Just as we allow a line-break where a semicolon is expected in a list of
statements.

-1 on making trailing commas mandatory, just as I'm against making
semicolons mandatory again :-)

···

On 5/11/16 14:29, Ricardo Parada via swift-evolution wrote:

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"
   ]

--
Rainer Brockerhoff <rainer@brockerhoff.net>
Belo Horizonte, Brazil
"In the affairs of others even fools are wise
In their own business even sages err."

43

Fully support your opinion.

> PS: can they actually be removed EVERYWHERE instead?!

Yes, I believe it will be much better to propose feature to allow line break instead of comma, so we can have:

let x = [10
  20
  30]

let y = [1 : "one"
  2 : "two"]

(from proposal):

func padStringToLength(
     sourceString: String
     destinationCount: Int
     paddingStyle: StringPaddingStyle = .Left
     paddingCharacter: Character = " "
) -> String {
     /* ... */
}

padStringToLength(
     sourceString: "source"
     destinationCount: 4
     paddingStyle: .Right
     paddingCharacter: ""
)

let tuple: (
     string: String
     number: Int
) = (
    string: "string"
    number: 0
)

... <SomeT
  SomeU
  > ...

This solves all the problems with diffs, makes code much clean and nice, no additional noise. Why we need these commas instead of this solution? IMO this will be real step forward.

Is there such a proposal? (Or probably was discussed already?)

···

On 12.05.2016 7:46, L Mihalkovic via swift-evolution wrote:

-1 - for ever

On May 11, 2016, at 6:47 PM, Joe Groff via swift-evolution >> <swift-evolution@swift.org <mailto: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:

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

44

Inline

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

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

[swift-evolution] [Rejected] SE-0009 Require self for accessing instance members

Got it. I expect you(the core team) will not be against new line as item separator in list(in addition to comma) just for the same reason. Also just for the same reason IMO you should not be against type inference for default parameters in funcs. etc
I find this rationale very 'wide' so we can end up with JavaScript(in worst meaning) instead of Swift at the end.

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.

For me this does not rationale why we need to introduce this 'feature' in Swift. There is a lot of 'cool'(or ugly, from someone's point of view) 'features' in these languages.
And we *have* trailing comma for arrays/dicts - IMO this is a golden middle between both words.

···

On 11.05.2016 22:58, Joe Groff wrote:

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

-Joe.

45

+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,
   )

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

I wouldn't mind it. The standard library already uses this style for function parameters, modulo the trailing comma, and I certainly prefer it to:
  

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

-Joe

···

On May 12, 2016, at 4:47 PM, Chris Lattner <clattner@apple.com> wrote:
On May 11, 2016, at 9:47 AM, Joe Groff <jgroff@apple.com> wrote:

46

I find it symptomatic that the 'popular' languages where this is allowed all seem to be rooted in scripting++ rather than in hard core, strong grammar languages. But i guess the two shall at some point meet... in swift?!

Could the feature perhaps be reserved for SwiftScript 1.0 then, instead of added to Swift 3.0? The situation somehow reminds me of Martin Orderski's early decision to make XML a first class citizen in Scala to fish for more audience, and his recent about face and cleaning up of the grammar.

Regards
(From mobile)

···

On May 12, 2016, at 6:31 PM, Erica Sadun via swift-evolution <swift-evolution@swift.org> wrote:

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

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

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

47

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

me too — so, for the review-part: -0.5, no trailing commas (it's not a full -1 as long as I'm not forced to add those trailing commas)
I don't think they are convenient, and even if that is wrong: The convenience-argument could be used to cripple the language (skipping closing parens could be convenient, using "l" and "v" instead of "let" & "var" could be convenient, inferring the return-type of methods could be convenient... and possibly hundreds of small changes in the syntax as well).
The idea of using newlines as separators (making "," obsolete, like ";" in other situations) imho is much nicer and would address the same issues that this proposal tries to improve.

48

+1

···

On 11 May 2016, at 9:11, Erica Sadun via swift-evolution wrote:

On May 11, 2016, at 9:42 AM, Evan Maloney <emaloney@gilt.com> wrote:

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

;-)

:P

One of the most interesting things about this whole comma proposal is how Swifty ("keeping in the feel and direction of Swift") it is to use multiple lines for functions and methods both in definition and at call sites. Swift may be "succinct" but in terms of generics, defaults, and external labels, it's absolutely ridiculous to try to limit signatures to single lines. The only way to deal with common Swift complexity is to structure what in any other language would be a single line into multiple lines. Here are a couple of examples pulled from stdlib:

  public func split(
    separator: Iterator.Element,
    maxSplits: Int = Int.max,
    omittingEmptySubsequences: Bool = true
  ) -> [SubSequence] { ... }

and

public func transcode<
  Input : IteratorProtocol,
  InputEncoding : UnicodeCodec,
  OutputEncoding : UnicodeCodec
  where InputEncoding.CodeUnit == Input.Element

(

  _ input: Input,
  from inputEncoding: InputEncoding.Type,
  to outputEncoding: OutputEncoding.Type,
  stoppingOnError stopOnError: Bool,
  sendingOutputTo processCodeUnit: @noescape (OutputEncoding.CodeUnit) -> Void
) -> Bool { ... }

My call for commas crosses into two other discussions that are happening right now on Swift Evolution: moving where clauses to the end of declarations (yes please) and whether to force defaulted parameters to appear in order at call sites (no thank you). Thinking about commas from this point of view can be disconcerting because when you think "What is Swift", the phrase that pops to mind is always "clarity and concision" but real world Swift declarations are anything but. Clear? They can be with carefully considered folding. Concise? Not especially.

I hope that anyone considering this proposal will think carefully about real world Swift like the examples I've pasted above and the others I've used in previous replies rather than some theoretical ideal where excess punctuation at the end of a declaration or call site is an actual silly eyesore:

func foo(a: T, b: U,) // not especially reflective of real world use

Because in the end this proposal should succeed or fail based on actual code enhancement and the gains that are to be accrued in real world use and not due to a simple taste factor.

-- E

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

49

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

;-)

:P

One of the most interesting things about this whole comma proposal is how Swifty ("keeping in the feel and direction of Swift") it is to use multiple lines for functions and methods both in definition and at call sites. Swift may be "succinct" but in terms of generics, defaults, and external labels, it's absolutely ridiculous to try to limit signatures to single lines. The only way to deal with common Swift complexity is to structure what in any other language would be a single line into multiple lines. Here are a couple of examples pulled from stdlib:

  public func split(
    separator: Iterator.Element,
    maxSplits: Int = Int.max,
    omittingEmptySubsequences: Bool = true
  ) -> [SubSequence] { ... }

and

public func transcode<
  Input : IteratorProtocol,
  InputEncoding : UnicodeCodec,
  OutputEncoding : UnicodeCodec
  where InputEncoding.CodeUnit == Input.Element

(

  _ input: Input,
  from inputEncoding: InputEncoding.Type,
  to outputEncoding: OutputEncoding.Type,
  stoppingOnError stopOnError: Bool,
  sendingOutputTo processCodeUnit: @noescape (OutputEncoding.CodeUnit) -> Void
) -> Bool { ... }

My call for commas crosses into two other discussions that are happening right now on Swift Evolution: moving where clauses to the end of declarations (yes please) and whether to force defaulted parameters to appear in order at call sites (no thank you). Thinking about commas from this point of view can be disconcerting because when you think "What is Swift", the phrase that pops to mind is always "clarity and concision" but real world Swift declarations are anything but. Clear? They can be with carefully considered folding. Concise? Not especially.

I hope that anyone considering this proposal will think carefully about real world Swift like the examples I've pasted above and the others I've used in previous replies rather than some theoretical ideal where excess punctuation at the end of a declaration or call site is an actual silly eyesore:

func foo(a: T, b: U,) // not especially reflective of real world use

Because in the end this proposal should succeed or fail based on actual code enhancement and the gains that are to be accrued in real world use and not due to a simple taste factor.

-- E

···

On May 11, 2016, at 9:42 AM, Evan Maloney <emaloney@gilt.com> wrote:

50

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

;-)

:P

One of the most interesting things about this whole comma proposal is how Swifty ("keeping in the feel and direction of Swift") it is to use multiple lines for functions and methods both in definition and at call sites. Swift may be "succinct" but in terms of generics, defaults, and external labels, it's absolutely ridiculous to try to limit signatures to single lines. The only way to deal with common Swift complexity is to structure what in any other language would be a single line into multiple lines. Here are a couple of examples pulled from stdlib:

  public func split(
    separator: Iterator.Element,
    maxSplits: Int = Int.max,
    omittingEmptySubsequences: Bool = true
  ) -> [SubSequence] { ... }

and

public func transcode<
  Input : IteratorProtocol,
  InputEncoding : UnicodeCodec,
  OutputEncoding : UnicodeCodec
  where InputEncoding.CodeUnit == Input.Element
>(
  _ input: Input,
  from inputEncoding: InputEncoding.Type,
  to outputEncoding: OutputEncoding.Type,
  stoppingOnError stopOnError: Bool,
  sendingOutputTo processCodeUnit: @noescape (OutputEncoding.CodeUnit) -> Void
) -> Bool { ... }

My call for commas crosses into two other discussions that are happening right now on Swift Evolution: moving where clauses to the end of declarations (yes please) and whether to force defaulted parameters to appear in order at call sites (no thank you). Thinking about commas from this point of view can be disconcerting because when you think "What is Swift", the phrase that pops to mind is always "clarity and concision" but real world Swift declarations are anything but. Clear? They can be with carefully considered folding. Concise? Not especially.

I hope that anyone considering this proposal will think carefully about real world Swift like the examples I've pasted above and the others I've used in previous replies rather than some theoretical ideal where excess punctuation at the end of a declaration or call site is an actual silly eyesore:

func foo(a: T, b: U,) // not especially reflective of real world use

Because in the end this proposal should succeed or fail based on actual code enhancement and the gains that are to be accrued in real world use and not due to a simple taste factor.

+1

···

Sent from my iPad

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

On May 11, 2016, at 9:42 AM, Evan Maloney <emaloney@gilt.com> wrote:

-- E

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

51

I agree.

···

On May 12, 2016, at 3:36 AM, Vladimir.S via swift-evolution <swift-evolution@swift.org> wrote:

Fully support your opinion.

> PS: can they actually be removed EVERYWHERE instead?!

Yes, I believe it will be much better to propose feature to allow line break instead of comma, so we can have:

let x = [10
   20
   30]

let y = [1 : "one"
   2 : "two"]

(from proposal):

func padStringToLength(
   sourceString: String
   destinationCount: Int
   paddingStyle: StringPaddingStyle = .Left
   paddingCharacter: Character = " "
) -> String {
   /* ... */
}

padStringToLength(
   sourceString: "source"
   destinationCount: 4
   paddingStyle: .Right
   paddingCharacter: ""
)

let tuple: (
   string: String
   number: Int
) = (
  string: "string"
  number: 0
)

... <SomeT
   SomeU
   > ...

This solves all the problems with diffs, makes code much clean and nice, no additional noise. Why we need these commas instead of this solution? IMO this will be real step forward.

Is there such a proposal? (Or probably was discussed already?)

On 12.05.2016 7:46, L Mihalkovic via swift-evolution wrote:

-1 - for ever

On May 11, 2016, at 6:47 PM, Joe Groff via swift-evolution >>> <swift-evolution@swift.org <mailto: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:

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

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

52

I'm +1 on allowing either trailing commas *or* a line-break instead of
where a comma is expected.

Just as we allow a line-break where a semicolon is expected in a list of
statements.

Well.. Although I'm still -1 on allowing trailing comma anywhere other than array/dict initialization, and think we need just line-breaks as separator, I feel(am I wrong?) like core team wants to accept the initial proposal(at least replies from @apple.com are supporting the initial proposal).

So, I believe this proposal(SE-0084) should be changed to something like:
"Allow trailing commas *everywhere* in comma-separated lists(parameters, tuples, generic type list, func/method call,etc) *and* allow line-break to be treated as a separator in comma-separated lists"

I believe such changed proposal, if will be accepted, will suite the needs of most developers - trailing comma + line-breaks.

But again.. will you use comma as separator in multi-line list if you can just don't type it and 'use' line-break? Do you use semicolons in code now? ;-)

-1 on making trailing commas mandatory, just as I'm against making
semicolons mandatory again :-)

OK. Probably I was wrong regarding my suggestion to make them mandatory.

···

On 12.05.2016 16:22, Rainer Brockerhoff via swift-evolution wrote:

53

  --- 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,
   )

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

I wouldn't mind it.

I personally find that style repulsive :-) and I haven’t seen swift code commonly doing it. I’m not sure that we want to encourage it either.

The standard library already uses this style for function parameters, modulo the trailing comma, and I certainly prefer it to:
  

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

I agree that this is even worse, but I also haven’t seen this used in Swift code. Have you? Swift’s strictness with argument labels makes any of this pretty unappealing to use.

If we were really concerned about this, a narrower way to solve the same problem would be to allow a comma before the ), but *only* when there is a newline between them. I still don’t see why we’d want to encourage this though.

-Chris

···

On May 12, 2016, at 4:50 PM, Joe Groff <jgroff@apple.com> wrote:

54

Tino, would you like to form an 'official' proposal for this(newlines as separators) feature? As I can see, there is a much support in community for this idea, but no one said yet he/she will create a proposal for this.(or I just missed this)

It seems like we'll need separate proposal for this, as 'traliling commas' proposal already in review and probably(I don't know) will be accepted(I saw support in comments from @apple.com)

···

On 14.05.2016 20:53, Tino Heth via swift-evolution wrote:

The idea of using newlines as separators (making "," obsolete, like ";" in
other situations) imho is much nicer and would address the same issues that
this proposal tries to improve.

55

I'm +1 on allowing either trailing commas *or* a line-break instead of
where a comma is expected.

Just as we allow a line-break where a semicolon is expected in a list of
statements.

Well.. Although I'm still -1 on allowing trailing comma anywhere other
than array/dict initialization, and think we need just line-breaks as
separator, I feel(am I wrong?) like core team wants to accept the
initial proposal(at least replies from @apple.com are supporting the
initial proposal).

So, I believe this proposal(SE-0084) should be changed to something like:
"Allow trailing commas *everywhere* in comma-separated lists(parameters,
tuples, generic type list, func/method call,etc) *and* allow line-break
to be treated as a separator in comma-separated lists"

I believe such changed proposal, if will be accepted, will suite the
needs of most developers - trailing comma + line-breaks.

Agreed. Everyone can use whatever feels best. Teams will mandate some
specific style, anyway.

But again.. will you use comma as separator in multi-line list if you
can just don't type it and 'use' line-break? Do you use semicolons in
code now? ;-)

I use commas with items on the same line, and semicolons with statements
on the same line. ;-)

Now, the choice of when to put items or statements on the same line
varies...

···

On 5/12/16 10:52, Vladimir.S via swift-evolution wrote:

On 12.05.2016 16:22, Rainer Brockerhoff via swift-evolution wrote:

--
Rainer Brockerhoff <rainer@brockerhoff.net>
Belo Horizonte, Brazil
"In the affairs of others even fools are wise
In their own business even sages err."

56

Don't be too harsh :-) This style can be used with much profit when there are several closure arguments:

  foo(
      x: {
          // several lines of code
      },
      y: {
          // several lines of code
      }
  )

For example: https://github.com/groue/GRDBDemo/blob/cd8b9d5cadc3c6c66fd0da4869d820c6624fdf79/GRDBDemo/PersonsViewController.swift#L12-L44

Gwendal Roué

···

Le 13 mai 2016 à 07:01, Chris Lattner via swift-evolution <swift-evolution@swift.org> a écrit :

On May 12, 2016, at 4:50 PM, Joe Groff <jgroff@apple.com> wrote:

  --- 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,
   )

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

I wouldn't mind it.

I personally find that style repulsive :-) and I haven’t seen swift code commonly doing it. I’m not sure that we want to encourage it either.

57

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

I wouldn't mind it.

I personally find that style repulsive :-) and I haven’t seen swift code commonly doing it. I’m not sure that we want to encourage it either.

No. Tell us what you *really* think of the style. Don't hold back.[1]

If we were really concerned about this, a narrower way to solve the same problem would be to allow a comma before the ), but *only* when there is a newline between them. I still don’t see why we’d want to encourage this though.

I wouldn't object to this restriction. I cannot think of a situation where using ",)" -- that is the comma adjacent to a closing parenthesis -- makes sense for any reason previously enumerated in support of this proposal.

-- E

[1] "Swift is an opinionated language" - C. Lattner

···

On May 12, 2016, at 11:01 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:

On May 12, 2016, at 4:50 PM, Joe Groff <jgroff@apple.com> wrote:

58

IMO If we were *really* concerned about this, we should just allow line-break as separator in comma-separated lists.

···

On 13.05.2016 8:01, Chris Lattner via swift-evolution wrote:

If we were really concerned about this, a narrower way to solve the same problem would be to allow a comma before the ), but *only* when there is a newline between them. I still don’t see why we’d want to encourage this though.

59

Regards
(From mobile)

   --- 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,
    )

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

I wouldn't mind it.

I personally find that style repulsive :-) and I haven’t seen swift code commonly doing it. I’m not sure that we want to encourage it either.

The standard library already uses this style for function parameters, modulo the trailing comma, and I certainly prefer it to:
   

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

I agree that this is even worse, but I also haven’t seen this used in Swift code. Have you? Swift’s strictness with argument labels makes any of this pretty unappealing to use.

If we were really concerned about this, a narrower way to solve the same problem would be to allow a comma before the ), but *only* when there is a newline between them. I still don’t see why we’d want to encourage this though.

did I read it correctly: "swift allows (rogue) commas at the end of a method invocation iif it is immediately followed by a single newline, itself followed by any amount of whitespace characters and a closing bracket". will it satisfy the people it is designed to appeal to?

···

On May 13, 2016, at 7:01 AM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:
On May 12, 2016, at 4:50 PM, Joe Groff <jgroff@apple.com> wrote:

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

60

I do it quite a lot, especially for initialising structs, enums. I use it to get the same benefits as a switch statement spread over several lines.

I think it’s often good to liberally apply new lines, as it aids legibility.

Here some sample code of mine using it:

extension ImageGraphic : JSONObjectRepresentable {
  public init(source: JSONObjectDecoder) throws {
    try self.init(
      imageSource: source.decode("imageSource"),
      width: source.decodeOptional("width"),
      height: source.decodeOptional("height")
    )
  }
  
  public func toJSON() -> JSON {
    return .ObjectValue([
      "imageSource": imageSource.toJSON(),
      "width": width.toJSON(),
      "height": height.toJSON()
    ])
  }
}

···

On 13 May 2016, at 3:01 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:

On May 12, 2016, at 4:50 PM, Joe Groff <jgroff@apple.com> wrote:

  --- 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,
   )

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

I wouldn't mind it.

I personally find that style repulsive :-) and I haven’t seen swift code commonly doing it. I’m not sure that we want to encourage it either.

The standard library already uses this style for function parameters, modulo the trailing comma, and I certainly prefer it to:
  

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

I agree that this is even worse, but I also haven’t seen this used in Swift code. Have you? Swift’s strictness with argument labels makes any of this pretty unappealing to use.

If we were really concerned about this, a narrower way to solve the same problem would be to allow a comma before the ), but *only* when there is a newline between them. I still don’t see why we’d want to encourage this though.

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