Hi,
I have a problem with tuple parameter types in a closure. Is this a language restriction or a bug in the Swift compiler? I used the Swift shipped with Xcode beta 3, also tried in Swift 2.2.
let d: [Int: String] = [1:"1", 0:"0"]
let e = d.sorted(isOrderedBefore: { e1, e2 in e1.0 < e2.0 }) // works
let f = d.sorted(isOrderedBefore: { (k1, v1), (k2, v2) in k1 < k2 }) // does not compile
Best,
Fabian
Zhao_Xin
(Zhao Xin)
3
I think this should consider as a bug because the Xcode editor suggests the
second way but the compiler can't compile.
Zhaoxin
···
On Wed, Jul 20, 2016 at 4:08 PM, Fabian Ehrentraud via swift-evolution < swift-evolution@swift.org> wrote:
Hi,
I have a problem with tuple parameter types in a closure. Is this a
language restriction or a bug in the Swift compiler? I used the Swift
shipped with Xcode beta 3, also tried in Swift 2.2.
let d: [Int: String] = [1:"1", 0:"0"]
let e = d.sorted(isOrderedBefore: { e1, e2 in e1.0 < e2.0 }) // works
let f = d.sorted(isOrderedBefore: { (k1, v1), (k2, v2) in k1 < k2 }) //
does not compile
Best,
Fabian
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
Ok, I created an issue: [SR-2135] Multiple Tuple Parameters to a Closure cannot be Decomposed in the Parameter List · Issue #44743 · apple/swift · GitHub
lg,
Fabian Ehrentraud
Mobile Developer
···
____________________________________
willhaben internet service GmbH & Co KG
Landstraßer Hauptstraße 97-101, 1030 Wien
M +43 699 1003 1604
DVR 4011331
Firmenbuch Nr. FN 271792 w
Gerichtsstand Handelsgericht Wien
UID Nr. ATU62251468
On 20.07.2016, at 12:07, Zhao Xin <owenzx@gmail.com<mailto:owenzx@gmail.com>> wrote:
I think this should consider as a bug because the Xcode editor suggests the second way but the compiler can't compile.
Zhaoxin
On Wed, Jul 20, 2016 at 4:08 PM, Fabian Ehrentraud via swift-evolution <swift-evolution@swift.org<mailto:swift-evolution@swift.org>> wrote:
Hi,
I have a problem with tuple parameter types in a closure. Is this a language restriction or a bug in the Swift compiler? I used the Swift shipped with Xcode beta 3, also tried in Swift 2.2.
let d: [Int: String] = [1:"1", 0:"0"]
let e = d.sorted(isOrderedBefore: { e1, e2 in e1.0 < e2.0 }) // works
let f = d.sorted(isOrderedBefore: { (k1, v1), (k2, v2) in k1 < k2 }) // does not compile
Best,
Fabian
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org<mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution
It's error by design: we don't allow tuple unpacking in closure parameters. Another example:
func call(block: ((Int, Int)) -> Int) // note double parens
call { (a, b) in print(a + b) } // will be error
call { (a) in print(a.0 + a.1) } // ok
Is there a reason for this design, or would it be possible / make sense to support this?
F
It's error by design: we don't allow tuple unpacking in closure parameters.
Another example:
func call(block: ((Int, Int)) -> Int) // note double parens
call { (a, b) in print(a + b) } // will be error
call { (a) in print(a.0 + a.1) } // ok
Sorry, did not send to evolution the first time.
We usually refer to SE-0029 "Remove implicit tuple splat", although it does
not specifically mention closures.
I would suggest to start discussion on your (additive) change after 07/30.
VladimirS
(Vladimir)
7
It's error by design: we don't allow tuple unpacking in closure parameters. Another example:
func call(block: ((Int, Int)) -> Int) // note double parens
call { (a, b) in print(a + b) } // will be error
call { (a) in print(a.0 + a.1) } // ok
Is there a reason for this design, or would it be possible / make sense to support this?
I believe because there is a question: is `(a,b)` is a list of two parameters or unpacked tuple? The closure definition requires one tuple parameter.
But probably such syntax could be used to define unpacked tuple in parameters :
call { ((a, b)) in print(a + b) } // note double parens
this feels consistent with tuple definition ((Int, Int)), the question here is if such syntax is not-confusing and is clear about arguments.
In any case this is additive feature, so we should discuss it after Swift 3.0
···
On 21.07.2016 12:33, Fabian Ehrentraud via swift-evolution wrote:
F
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
