[swift-evolution] Proposal: Always flatten the single element tuple

Vladimir.S svabox at gmail.com
Thu Jun 8 16:27:17 CDT 2017


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 
>> <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> 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
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
> 


More information about the swift-evolution mailing list