<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Tue, May 10, 2016 at 11:53 AM Chris Lattner via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello Swift community,<br>
<br>
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:<br>
<br>
<a href="https://github.com/apple/swift-evolution/blob/master/proposals/0084-trailing-commas.md" rel="noreferrer" target="_blank">https://github.com/apple/swift-evolution/blob/master/proposals/0084-trailing-commas.md</a><br>
<br> * What is your evaluation of the proposal?<br></blockquote><div><br></div><div>-1. It makes more sense to allow this for arrays and dictionaries because are variable-length collections whose literals are much more likely to grow as a code base evolves (anecdotal personal experience). Tuples are fixed arity, so proactively protecting oneself with a trailing comma seems like it would have minimal benefit when the surrounding code would have to change in other ways.</div><div><br></div><div>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.</div><div><br></div><div>Essentially, my argument draws a line between "content" changes where we should allow this (i.e., you can add an element to an array or dictionary and the code that uses it works as expected, just iterates over the additional elements) vs. "structural" changes where we should not (adding an element to a tuple or a function call is likely to involve changes to surrounding code as well, so the savings are minimal).</div><div><br></div><div><span style="line-height:1.5"> </span><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* Is the problem being addressed significant enough to warrant a change to Swift?<br></blockquote><div><br></div><div>I don't believe so. This feels like a language change that would only produce cleaner diffs in isolated places in source control. The cases where one would proactively want to protect themselves against future changes using this syntax don't seem to warrant a grammar change.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* Does this proposal fit well with the feel and direction of Swift?</blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?</blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* How much effort did you put into your review? A glance, a quick reading, or an in-depth study?<br></blockquote><div><br></div><div>I read the proposal.</div><div><br></div></div></div>