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

[John McCall]

> On Apr 14, 2016, at 10:28 PM, Chris Lattner <clattner at apple.com> wrote:
> 
> 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.

"Special case" is a loaded phrase.  Why is it a special case as a parameter if it isn't a special case as a result?

>  In many places in the Swift grammar we aim for consistency, even if it means a bit more punctuation in specific cases.

This is not greatly in evidence.  We have a lot of special-case syntax.

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

The grammatical and semantic purpose of parentheses is identical in both grammars.

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

So we should require function argument labels in function types?

John.