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

[Gwendal Roué]

Xiaodi, Adrian, you are actively pushing so that something that was allowed, well compiled (no runtime issue), and covered actual uses cases, becomes forbidden. Without any developer advantage that would somehow balance the change.

That's called a regression.

And what's the rationale, already? A sense of compiler aesthetics? Since when a sense of compiler aesthetics is more valuable than a sense of code aesthetics? Aren't both supposed to walk together as a pair?

Gwendal

> Le 7 juin 2017 à 12:54, Xiaodi Wu <xiaodi.wu at gmail.com> a écrit :
> 
> IMO, if tuples and argument lists are to be distinguished in any way, it is imperative that f3(+) and f4(+), and some of your other examples, _not_ work.
> 
> After all, if a tuple is not an argument list, it should possible to have a function of type ((Int, Int)) -> Int and a function of type (Int, Int) -> Int share the same name (IIUC, it’s a known bug that this does not currently work). Quite simply, there’s a type mismatch if you pass sum1 to f3–what happens if there’s a distinct, overloaded sum1 that takes a single tuple?
> 
> Chris’s suggestion restores a syntactic convenience without touching the type system. What you are arguing for is essentially making ((Int, Int)) -> Int and (Int, Int) -> Int synonymous again, either in some or in all contexts.
> 
> 
> On Wed, Jun 7, 2017 at 05:41 Gwendal Roué via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> Le 7 juin 2017 à 12:33, Gwendal Roué <gwendal.roue at gmail.com <mailto:gwendal.roue at gmail.com>> a écrit :
>> 
>> 
>>> Le 7 juin 2017 à 12:03, Adrian Zubarev via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> a écrit :
>>> 
>>> 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 }
>>> 
>> 
>> Despite Chris Lattern being a semi-god, his double-parenthesis suggestion cruelly lacks in terms of user ergonomics. The compiler should be able to deal with the following code snippet, just like Swift 3 does:
>> 
>>     // two arguments
>>     func f1(_ closure: (Int, Int) -> Int) { closure(1, 2) }
> 
>> [...]
> 
> Here is the full extent of the remarquable Swift 3 ergonomics. This full snippet compiles in Swift 3:
> 
>     func sum1(_ lhs: Int, _ rhs: Int) -> Int { return lhs + rhs }
>     func sum2(lhs: Int, rhs: Int) -> Int { return lhs + rhs }
>     func sum3(tuple: (Int, Int)) -> Int { return tuple.0 + tuple.1 }
>     func sum4(tuple: (lhs: Int, rhs: Int)) -> Int { return tuple.lhs + tuple.rhs }
> 
>     // two arguments
>     func f1(_ closure: (Int, Int) -> Int) { closure(1, 2) }
>     f1 { lhs, rhs in lhs + rhs }
>     f1 { (lhs, rhs) in lhs + rhs }
>     f1 { tuple in tuple.0 + tuple.1 }
>     f1 { (tuple) in tuple.0 + tuple.1 }
>     f1(+)
>     f1(sum1)
>     f1(sum2)
>     f1(sum3)
>     f1(sum4)
>     
>     // two arguments, with documentation names: identical
>     func f2(_ closure: (_ a: Int, _ b: Int) -> Int) { closure(1, 2) }
>     f2 { lhs, rhs in lhs + rhs }
>     f2 { (lhs, rhs) in lhs + rhs }
>     f2 { tuple in tuple.0 + tuple.1 }
>     f2 { (tuple) in tuple.0 + tuple.1 }
>     f2(+)
>     f2(sum1)
>     f2(sum2)
>     f2(sum3)
>     f2(sum4)
>     
>     // one tuple argument
>     func f3(_ closure: ((Int, Int)) -> Int) { closure((1, 2)) }
>     f3 { lhs, rhs in lhs + rhs }
>     f3 { (lhs, rhs) in lhs + rhs }
>     f3 { tuple in tuple.0 + tuple.1 }
>     f3 { (tuple) in tuple.0 + tuple.1 }
>     f3(+)
>     f3(sum1)
>     f3(sum2)
>     f3(sum3)
>     f3(sum4)
>     
>     // one keyed tuple argument
>     func f4(_ closure: ((a: Int, b: Int)) -> Int) { closure((a: 1, b: 2)) }
>     f4 { lhs, rhs in lhs + rhs }
>     f4 { (lhs, rhs) in lhs + rhs }
>     f4 { tuple in tuple.a + tuple.b }
>     f4 { (tuple) in tuple.a + tuple.b }
>     f4(+)
>     f4(sum1)
>     f4(sum2)
>     f4(sum3)
>     f4(sum4)
> 
> Gwendal
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170607/ff66c604/attachment.html>