<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Wed, May 11, 2016 at 8:09 AM Erica Sadun via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><br></div></div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>To summarize the complaints to date:</div><div><br></div><div>* It make code read like errors</div><div>* Arrays and dictionaries are different &quot;things&quot; than parameters and tuples; They are structurally different</div><div>* Parameter lists should always be of fixed size at deployment time; Once a signature is fixed and consumed, it&#39;s difficult to change</div><div><br></div><div>To which I reply:</div><div><br></div><div>* Well structured code needn&#39;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.</div><div>* 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.</div><div>* Parameter lists and function signatures, like collections, can evolve, especially when using defaulted parameters, even when they are consumed at multiple points.</div></div></blockquote><div><br></div><div><span style="line-height:1.5">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&#39;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?</span><br></div><div><br></div><div>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&#39;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?<br></div><div><br></div><div>Since you alluded to teaching earlier as a scenario to consider, in my (anecdotal, of course) experience teaching CS, I&#39;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 (&quot;does it have a different meaning?&quot; &quot;is there an empty item in this list?&quot;, etc.). That harkens back to concerns that trailing commas make code look like there&#39;s something &quot;missing&quot; or &quot;left out.&quot;</div><div><br></div><div>Of course, the argument could be made that I personally would be mostly unaffected by this change—I don&#39;t use trailing commas now and this proposal wouldn&#39;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&#39;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.</div><div><br></div></div></div>