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

[Thorsten Seitz]

+1

I am against introducing more parentheses because the resulting code is much more unreadable IMO (those additional parentheses will typically appear in argument lists, which means that the additional parentheses will be nested in the parentheses of the argument list). As someone else said, the arrow already clearly marks this as a function type and clearly separates argument from result type. Adding parentheses is just adding punctuation noise.

-Thorsten 

Am 15.04.2016 um 22:23 schrieb Brent Royal-Gordon via swift-evolution <swift-evolution at swift.org>:

>> 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?
> 
> While it's technically correct, I agree with John's assessment that this is "fussy". `T -> U` doesn't confuse people and doesn't confuse the compiler; removing it would require extra punctuation for no particular reason. It would also become inconsistent with the paren-less `{ param in … }` syntax, which I think is very important for keeping usage sites simple and clean.
> 
> What I think we *should* eliminate, however, is using `Void` to mean "no arguments" in a closure type. `Void -> Int` should mean that the type takes one argument which happens to be an empty tuple. If you want no arguments, write `() -> Int`. Similarly, a typedef for a 2-tuple (like `Dictionary.Element`) should be recognized as one tuple parameter, not two singleton parameters. With that in place, `T -> U` becomes merely a convenient shorthand for the canonical form, `(T) -> U`.
> 
> I mean, it's not that big a deal; if you remove it, everyone will type extra parentheses and live with it. But recognize that doing so would improve the language, not the end-user experience.
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution