I also ran into this issue recently with SR-4745 <https://bugs.swift.org/browse/SR-4745>. It also same up in comments on SR-2008 <https://bugs.swift.org/browse/SR-2008>. It looks like the issue was discussed here on SE <http://discourse.natecook.com/t/pitch-tuple-destructuring-in-parameter-lists/1501> exactly year ago.
Turns out Swift does not support tuple destructuring in closure arguments. Only in let statement and for-in. What previously worked for simple cases (not nested tuples) was some kind of side effect?! I strongly feel we need to address this in time for Swift 4, as the consequent implementation of SE-0110 seriously hobbles concise and readable functional style code. I'm partial to solution suggested by Raphael Reitzig as summarized by Ben Rimmington in comments on SR-2008 <https://bugs.swift.org/browse/SR-2008?focusedCommentId=22578&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-22578> : > > - tuple destructuring in parameter lists (which is currently not > supported); > - and for closure expressions, disallowing single parentheses around > multiple parameters, or requiring double parentheses for tuple > destructuring. > > and One could be ambitious and propose general destructuring (similar to > Scala). By using a keyword, backwards-compatibility and unambiguity could > be achieved. Example: { let (x,y,z) in ...} When asked about what would adding support for destructuring tuples in closure arguments entail in the compiler (could it for example reuse implementation from for-in), Jordan Rose said: It's 80% a new feature. The compiler would have to figure out what the > proper type of the closure is anyway (the hard part) and then assign from > that type into local variables for the destructured parameters (the easy > part). Please do take it to swift-evolution if you're interested! I don't think I can drive this to SE proposal at this moment. Any takers? --Pavol On Wed, May 24, 2017 at 9: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? > > (https://github.com/apple/swift-corelibs-foundation/pull/995/files) > > - Tony > > > _______________________________________________ > 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
