> On Apr 14, 2016, at 9:57 PM, Chris Lattner via swift-evolution > <swift-evolution@swift.org> wrote: > > We currently accept function type syntax without parentheses, like: > > Int -> Float > String -> () > > etc. The original rationale aligned with the fact that we wanted to treat > all functions as taking a single parameter (which was often of tuple type) > and producing a tuple value (which was sometimes a tuple, in the case of void > and multiple return values). However, we’ve long since moved on from that > early design point: there are a number of things that you can only do in a > parameter list now (varargs, default args, etc), implicit tuple splat has > been removed, and the compiler has long ago stopped modeling function > parameters this way. Beyond that, it eliminates one potential style war. > > Given all this, I think it makes sense to go for syntactic uniformity between > parameter list and function types, and just require parenthesis on the > argument list. The types above can be trivially written as: > > (Int) -> Float > (String) -> () > > Thoughts?
To me, the unparenthesized style suggests that the input and output are peers, which feels more natural for the sort of value-to-value transform/predicate where this most commonly occurs. Parenthesizing the input feels fussier, which contributes to a sense that the argument is just one component to producing the result. The parentheses are grammatically unnecessary in most cases (by frequency of use in higher-use programming, not by feature count). Our grammar generally allows grammatically-unnecessary parentheses to be omitted (except the C-style for loop, until we killed it) — I guess you could count function call syntax, but we had strong reasons there that don't seem to apply here. We notably chose to deviate from C statement grammar specifically to allow unnecessary parentheses to be omitted. This would feel weirdly inconsistent with that. I guess the flip side is that call and declaration syntax both require parentheses (unless the only argument is a trailing closure), but again, we had strong justifications for that: declarations would always be ambiguous without parens, and calls would have serious problems (and the style-wars factor would be much larger, especially now with mandatory keyword arguments by default). John. _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution