> Le 25 mai 2017 à 17:47, Nate Cook via swift-evolution
> <[email protected]> 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é
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
