[swift-evolution] Revisiting SE-0110

[Pavol Vaskovic]

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 <
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?
>
> (https://github.com/apple/swift-corelibs-foundation/pull/995/files)
>
> - Tony
>
>
> _______________________________________________
> 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/20170524/88471efd/attachment.html>