[swift-evolution] [pitch] Eliminate the "T1 -> T2" syntax, require "(T1) -> T2"

[Chris Lattner]

On Apr 14, 2016, at 10:21 PM, John McCall <rjmccall at apple.com> wrote:
> 
>> On Apr 14, 2016, at 9:57 PM, Chris Lattner via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> We currently accept function type syntax without parentheses, like:

> 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).  

I agree with your point that many simple higher order programming examples (e.g. map, filter, etc) take a single argument.  That said, I don’t agree that this means that we should syntactically privilege this special case.  In many places in the Swift grammar we aim for consistency, even if it means a bit more punctuation in specific cases.

> 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.

We allow parens to be omitted from control flow expressions, where they are redundant with paren exprs.  I don’t see how that translates to our type grammar.

> 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).

Right, but regardless of *why* we always require parens on Decls and ApplyExprs, we really do (and that isn’t going to change).  Being consistent between func decls and function types is quite important IMO.

-Chris