> On May 11, 2016, at 9:42 AM, Evan Maloney <[email protected]> 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
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
