On 08.06.2017 20:40, Brent Royal-Gordon via swift-evolution wrote:
On Jun 7, 2017, at 3:03 AM, Adrian Zubarev via swift-evolution
<[email protected] <mailto:[email protected]>> wrote:
Well please no:
|let fn2: ((Int, Int)) -> Void = { lhs, rhs in }|
Instead use destructuring sugar pitched by Chris Lattner on the other thread:
|let fn2: ((Int, Int)) -> Void = { ((lhs, rhs)) in }|
I think this suggestion is better than the status quo. I'm wondering, though, if we
should just drop the outer set of parentheses entirely, unless you're also putting
types on the parameters. That is, a closure of type `(Int, Int) -> T` can look like this:
{ (x: Int, y: Int) in … }
Or it can look like this:
{ x, y in … }
But it *cannot* look like this:
{ (x, y) in … }
The `(x, y)` form can instead be a closure of a type like `((Int, Int)) -> T`, which
immediately destructures the tuple parameter into separate constants.
The main problem with this suggestion, as I understand, is that {(x,y) in ..} in
Swift 3 is allowed for (Int,Int)->() closure. So, your proposal will also broke code
during the migration as ((Int,Int))->() will be sent where (Int,Int)->() is expected.
Also, personally, I see a big inconsistency when
{ (x: Int, y: Int) in ..}
declares closure of type (Int,Int)->(), but
{ (x, y) in ... }
for some reason declared closure of type ((Int,Int))->()
while currently we know that we are allowed to just omit type annotation in
closures.
And it seems naturally for me to see { ((x,y)) in ..} for closure of type
((Int,Int))->() - there is nice symmetry about these two pairs of parenthesis in
closure and in type syntax itself.
--
Brent Royal-Gordon
Architechies
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
