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

[L Mihalkovic]

-1 - for ever


> On May 11, 2016, at 6:47 PM, Joe Groff via swift-evolution <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 <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
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160512/b40ed25e/attachment.html>