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 > <[email protected]> wrote: > > >> On May 24, 2017, at 12:12 PM, Tony Parker via swift-evolution >> <[email protected]> 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 > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
