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

[Joshua Kopin]

+1

On 11 May 2016, at 9:11, Erica Sadun via swift-evolution wrote:

>> On May 11, 2016, at 9:42 AM, Evan Maloney <emaloney at gilt.com> wrote:
>>
>>> 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
>>
>> ;-)
>>
>>
>
> :P
>
> 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:
>
>   public func split(
>     separator: Iterator.Element,
>     maxSplits: Int = Int.max,
>     omittingEmptySubsequences: Bool = true
>   ) -> [SubSequence] { ... }
>
> and
>
> public func transcode<
>   Input : IteratorProtocol,
>   InputEncoding : UnicodeCodec,
>   OutputEncoding : UnicodeCodec
>   where InputEncoding.CodeUnit == Input.Element
>> (
>   _ input: Input,
>   from inputEncoding: InputEncoding.Type,
>   to outputEncoding: OutputEncoding.Type,
>   stoppingOnError stopOnError: Bool,
>   sendingOutputTo processCodeUnit: @noescape (OutputEncoding.CodeUnit) 
> -> Void
> ) -> Bool { ... }
>
> 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 
> "clarity and concision" but real world Swift declarations are anything 
> but.  Clear? They can be with carefully considered folding. Concise? 
> Not especially.
>
> 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:
>
> func foo(a: T, b: U,) // not especially reflective of real world use
>
> Because in the end this proposal should succeed or fail based on 
> actual code enhancement and the gains that are to be accrued in real 
> world use and not due to a simple taste factor.
>
> -- E
>
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution