[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