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

Thu May 12 07:18:05 CDT 2016

I agree. 

> On May 12, 2016, at 3:36 AM, Vladimir.S via swift-evolution <swift-evolution at 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
>    SomeV> ...
> 
> 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 at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>> 
>>> 
>>>> On May 10, 2016, at 11:53 AM, Chris Lattner via swift-evolution
>>>> <swift-evolution at swift.org <mailto:swift-evolution at 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 at swift.org <mailto:swift-evolution at swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> 
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution