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

[Vladimir.S]

After some discussions, I support this proposal and think this will make 
Swift more consistent and clear about where is parameters and where is 
result type. Especially this important in code like:
Int -> String -> Void -> Float
which IMO should be
(Int) -> (String) -> (Void) -> Float
as Int/String/Void are parameters, Float is result type.

But IMO not just "require parenthesis on the argument list", but also 
disallow parenthesis in result type in meaning of tuple of single 
argument(as we discussed in this thread with @Anton), disallow placing () 
in (), disallow Void in () in result - to prevent all these ((((())))) 
(((Void))) etc in parameters and in result type.

@Chris, would you form a proposal for this subject?

On 15.04.2016 7:57, Chris Lattner via swift-evolution 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?
>
> -Chris
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>