[swift-evolution] Revisiting SE-0110
gs.
griotspeak at gmail.com
Thu May 25 06:56:44 CDT 2017
I wish that we had gone in the other direction and let functions allow destructuring of parameters. That said, I guess I can see how that chance left when we decided to move away from function parameters as tuples.
TJ
> On May 25, 2017, at 02:08, Chris Lattner via swift-evolution <swift-evolution at swift.org> wrote:
>
>
>> On May 24, 2017, at 12:12 PM, Tony Parker via swift-evolution <swift-evolution at swift.org> wrote:
>>
>> Hi everyone,
>>
>> We received a pull request in swift-corelibs-foundation which is apparently in response to a language change for SE-0110.
>>
>> It turns this perfectly reasonable code:
>>
>> - self.forEach { (keyItem, valueItem) in
>>
>> into this:
>>
>>
>> + self.forEach { (arg) in
>> + let (keyItem, valueItem) = arg
>>
>> Is that really the design pattern we want to encourage? What was wrong with the previous code?
>
> 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.
>
> Similarly, this doesn’t compile either:
>
> self.ForEach(functionTakingTwoParameters)
>
> even if the two parameters are equivalent to the element type of the self Sequence
>
> -Chris
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170525/cbc23831/attachment.html>
More information about the swift-evolution
mailing list