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

[Erica Sadun]

> On Apr 19, 2016, at 9:44 AM, David Rönnqvist <david.ronnqvist at gmail.com> wrote:
> 
> Would this also affect the syntax for naming closure arguments? For example, would this (taken from "The Swift Programming Language (Swift 2.2)”):
>   reversed = names.sort( { s1, s2 in return s1 > s2 } )
> have to be written like this:
>   reversed = names.sort( { (s1, s2) in return s1 > s2 } )
> or is that a different syntax?
> 
> As a developer focused on _writing_ and _reading_ code like this, I don’t see the real benefits of this change. It only feels natural to me that I would be able to omit the parentheses when there is only one type, but that I would need them to group multiple arguments or to label arguments.
> 
> That said, I don’t feel strongly about it and the work of transitioning our code would be minimal. If this change provides other engineering benefits that aren’t noticeable on the surface, then I’m positive to the change for those reasons.
> 
> - David

It would not affect the closure syntax. To paraphrase Chris:
No. Swift’s syntactic shortcuts in its closure parameter lists benefit simple functional algorithms. Few people would choose to write fully specified long-form declarations when, for example, reverse-sorting an array of integers:

y = x.sorted { (lhs : Int, rhs : Int) -> Bool in rhs < lhs }
Compare the long form with this simpler form:

y = x.sorted { lhs, rhs in rhs < lhs }
You can use the even shorter form of { $1 < $0 }. 

Closures offer a structurally distinct class of syntactic sugar: 

You may elide parentheses (even with multiple arguments)
You may omit the return type
You may omit types
You may omit the parameter list in its entirety
Short of a complete rethink of closure syntax, requiring parentheses there would not improve the language in any measurable way.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160419/d2c11314/attachment.html>