[swift-evolution] Revisiting SE-0110

Gwendal Roué gwendal.roue at gmail.com
Thu May 25 11:09:35 CDT 2017

> Le 25 mai 2017 à 17:47, Nate Cook via swift-evolution <swift-evolution at swift.org> a écrit :
>> For consistency, the decision was to make closure parameter lists work the same way as function parameters. Function parameters do not allow destructuring of arguments in their declaration, so it seemed weird to let closures do that.
> I have to say that for me, it has never seemed weird at the use site to destructure tuples like that. The only confusion I've ever seen from users is when deconstruction didn't work enough, like if the parameter was (Int, (Int, Int)) and you couldn't destructure the nested tuple.

I even suggest that tuple destructuring gets more consideration.

That is because without restructuring, many closures that could be written as a single line have to be written with several lines (in order to explicitly destructure input tuples, as in the sample code provided by the OP):

+        self.forEach { (arg) in
+            let (keyItem, valueItem) = arg

Unfortunately, multiline closures are less nice than single line closures: multiline closures can't avoid the `return` keyword. And multiline closures have downgraded type inference:

func f<T>(_ closure: () -> T) -> T { return closure() }

// Yeah!
f { 1 }

// Meh: unable to infer complex closure return type; add explicit type to disambiguate
f {
    let x = 1
    return x

Of course, the type inference problem above could be fixed independently of tuple destructuring. But it looks like it is difficult to implement: see Jordan Rose's comment in https://bugs.swift.org/browse/SR-1570 <https://bugs.swift.org/browse/SR-1570> which links to https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151214/002583.html <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151214/002583.html>.

Gwendal Roué

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

More information about the swift-evolution mailing list