<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On May 11, 2016, at 9:42 AM, Evan Maloney <<a href="mailto:emaloney@gilt.com" class="">emaloney@gilt.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class=""><blockquote type="cite" class="">I’m going to propose the keyword #litter as an alias for , so I can throw garbage syntax into my code more effectively seven letters at time :P<br class=""></blockquote><br class="">;-)<br class=""><br class=""><br class=""></div></div></blockquote><br class=""></div><div>:P</div><br class=""><div class="">One of the most interesting things about this whole comma proposal is how Swifty ("keeping in the feel and direction of Swift") it is to use multiple lines for functions and methods both in definition and at call sites. Swift may be "succinct" but in terms of generics, defaults, and external labels, it's absolutely ridiculous to try to limit signatures to single lines. The only way to deal with common Swift complexity is to structure what in any other language would be a single line into multiple lines. Here are a couple of examples pulled from stdlib:</div><div class=""><div class=""><br class=""></div><div class=""><div class=""><font face="Menlo" class=""> public func split(</font></div><div class=""><font face="Menlo" class=""> separator: Iterator.Element,</font></div><div class=""><font face="Menlo" class=""> maxSplits: Int = Int.max,</font></div><div class=""><font face="Menlo" class=""> omittingEmptySubsequences: Bool = true</font></div><div class=""><font face="Menlo" class=""> ) -> [SubSequence] { ... }</font></div></div><div class=""><br class=""></div><div class="">and</div><div class=""><br class=""></div><div class=""><div class=""><font face="Menlo" class="">public func transcode<</font></div><div class=""><font face="Menlo" class=""> Input : IteratorProtocol,</font></div><div class=""><font face="Menlo" class=""> InputEncoding : UnicodeCodec,</font></div><div class=""><font face="Menlo" class=""> OutputEncoding : UnicodeCodec</font></div><div class=""><font face="Menlo" class=""> where InputEncoding.CodeUnit == Input.Element</font></div><div class=""><font face="Menlo" class="">>(</font></div><div class=""><font face="Menlo" class=""> _ input: Input,</font></div><div class=""><font face="Menlo" class=""> from inputEncoding: InputEncoding.Type,</font></div><div class=""><font face="Menlo" class=""> to outputEncoding: OutputEncoding.Type,</font></div><div class=""><font face="Menlo" class=""> stoppingOnError stopOnError: Bool,</font></div><div class=""><font face="Menlo" class=""> sendingOutputTo processCodeUnit: @noescape (OutputEncoding.CodeUnit) -> Void</font></div><div class=""><font face="Menlo" class="">) -> Bool { ... }</font></div></div></div><div class=""><br class=""></div><div class="">My call for commas crosses into two other discussions that are happening right now on Swift Evolution: moving where clauses to the end of declarations (yes please) and whether to force defaulted parameters to appear in order at call sites (no thank you). Thinking about commas from this point of view can be disconcerting because when you think "What is Swift", the phrase that pops to mind is always "<i class="">clarity and concision</i>" but real world Swift declarations are anything but. Clear? They can be with carefully considered folding. Concise? Not especially.</div><div class=""><br class=""></div><div class="">I hope that anyone considering this proposal will think carefully about real world Swift like the examples I've pasted above and the others I've used in previous replies rather than some theoretical ideal where excess punctuation at the end of a declaration or call site is an actual silly eyesore:</div><div class=""><br class=""></div><div class=""><font face="Menlo" class="">func foo(a: T, b: U,) // not especially reflective of real world use</font></div><div class=""><br class=""></div><div class="">Because in the end this proposal should succeed or fail based on <i class="">actual code enhancement </i>and the gains that are to be accrued in real world use and not due to a simple taste factor.</div><div class=""><br class=""></div><div class="">-- E</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div></body></html>