-1 - for ever

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

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

Reply via email to