--
Adrian Zubarev
Sent with Airmail
Am 7. Juni 2017 um 13:18:22, Gwendal Roué (gwendal.r...@gmail.com) schrieb:
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.
func foo(_: (Int, Int)) {}
func bar(_: Int, _: Int) {}
type(of: foo) == type(of: bar) //=> true - It's a BUG!
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...@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@swift.org> wrote:
Le 7 juin 2017 à 12:33, Gwendal Roué <gwendal.r...@gmail.com> a écrit :
Le 7 juin 2017 à 12:03, Adrian Zubarev via swift-evolution
<swift-evolution@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
