<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>I find it symptomatic that the 'popular' languages where this is allowed all seem to be rooted in scripting++ rather than in hard core, strong grammar languages. But i guess the two shall at some point meet... in swift?! </div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">Could the feature perhaps be reserved for SwiftScript 1.0 then, instead of added to Swift 3.0? The situation somehow reminds me of Martin Orderski's early decision to make XML a first class citizen in Scala to fish for more audience, and his recent about face and cleaning up of the grammar.<br><br><div>Regards</div>(From<span class="Apple-style-span" style="-webkit-tap-highlight-color: rgba(26, 26, 26, 0.296875); -webkit-composition-fill-color: rgba(175, 192, 227, 0.230469); -webkit-composition-frame-color: rgba(77, 128, 180, 0.230469); "> mobile)</span></div><div><br>On May 12, 2016, at 6:31 PM, Erica Sadun via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><div><meta http-equiv="Content-Type" content="text/html charset=utf-8"><br class=""><div><blockquote type="cite" class=""><div class="">On May 10, 2016, at 2:58 PM, Chris Lattner via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><div class=""><div style="font-family: Palatino-Roman; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><blockquote type="cite" class=""><div class="">On May 10, 2016, at 12:36 PM, Tony Allevato <<a href="mailto:allevato@google.com" class="">allevato@google.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="gmail_quote"><div dir="ltr" class="">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></div></div></blockquote><br class=""></div><div style="font-family: Palatino-Roman; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">FWIW, I personally agree with this observation.</div><div style="font-family: Palatino-Roman; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class=""></div><div style="font-family: Palatino-Roman; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">Parameter lists and tuples are also structurally different than collections. Parameter lists also have labels, and (depending on how the ‘disable reordering default arguments’ decision goes) parameters may not be added and reordered arbitrarily. Tuples are different because adding a member will often break all the code downstream because it changes the type of the value. This is different than array and dictionary literals.</div><div style="font-family: Palatino-Roman; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class=""></div><div style="font-family: Palatino-Roman; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">The only “collection like” aspect I can think of is for variadic parameter lists, but I don’t think they’re common enough to provide a special case for.</div></div></blockquote><br class=""></div><div><br class=""></div>I agree that the trailing comma offers its best support for situations that express variadic properties. I propose that all three of the following scenarios share this nature:<div class=""><ul class=""><li class="">At call sites with variadic arguments</li><li class="">At call sites with defaulted arguments</li><li class="">At definition sites with large complex argument lists or tuple members</li></ul><div class="">It's slightly easier to make the case for call sites, the first two of these uses, as they exactly mirror the way collections parse members. Supporting the third style of trailing commas requires the consideration of real world modern Swift. </div><div class=""><br class=""></div><div class="">Allowing cut and paste or commenting of entire parameter lines means simple changes do not ripple out to affect other lines. In this, trailing commas serve programmer intent and limit the effect in diff comparisons. As Joe pointed out in one of his responses on this thread, one edit becomes one diff, without extra housekeeping for other affected lines. When considered together, I do believe the use cases for these scenarios are common enough to be considered something other than a "special case". </div></div><div class=""><br class=""></div><div class="">Given that SE-0060 is accepted, the third case is narrowed but should not be ignored. Reordering and commenting out lines during prototyping, working in playgrounds, and scripting is still common. Also, a reorder or comment when trailing commas are permitted ensures that such changes are single-point edits. </div><div class=""><br class=""></div><div class="">As Brent points out in his review, "<span style="font-family: Palatino-Roman;" class="">I was skeptical of this until a week or two ago, when I had some code where I ended up commenting out certain parameters." Trailing commas, although a minor feature in a major language, still serves the developer and supports the overall philosophy of Swift, which is as you have pointed out multiple times, an opinionated language.</span></div><div class=""><span style="font-family: Palatino-Roman;" class=""><br class=""></span></div><div class=""><span style="font-family: Palatino-Roman;" class="">-- E</span></div><div class=""><span style="font-family: Palatino-Roman;" class=""><br class=""></span></div></div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></body></html>