> On Apr 19, 2016, at 9:44 AM, David Rönnqvist <[email protected]>
> 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._______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
