[swift-evolution] Revisiting SE-0110

Pavol Vaskovic pali at pali.sk
Thu Jun 1 16:39:13 CDT 2017

On Thu, Jun 1, 2017 at 8:52 PM, John McCall via swift-evolution <
swift-evolution at swift.org> wrote:

> I understand that there are developers who dislike SE-0110's impact on
> certain kinds of functional programming, but that is a very broad complaint
> that is unlikely to reach consensus or acceptance, especially for Swift 4.

The impact of SE-0110 as currently implemented in Swift 4 leads to
following migration choice wherever you have a closure that takes tuple
* concise but obfuscate code ($0.1, ...)
* readable but verbose code (requiring a ton of boilerplate: intermediate
argument, expand signature to include return type, desctructure tuple on
new line using let, add return clause)

Maybe I misunderstood you, but I don't think this is marginal issue
affecting only some "developers that dislike the impact on certain kinds of
functional programming".

This is a HUGE regression to the usability of all closure with tuple
arguments. I'd wager that is the prevailing consensual opinion of anyone
who has experienced this issue in practice.

I would go as far as to claim that current implementation of SE-0110 does
not conform to the Swift 4's goal of backwards source compatibility.

> In contrast, I think we may be able to gain consensus on a more targeted
> proposal that just re-admits tuple destructuring in closures, assuming we
> can find an acceptable implementation.

>From what I understand our options are quite limited because of tight
constraints of Swift 4's emphasis on backwards source-compatibility and
impending release deadline:

* effectively revert SE-0110 by always using the codepath for Swift 3
compatibility mode
* implement full tuple destructuring (unexplored issues with syntax and
backwards compatibility)

(Note that Swift 3 didn't support full tuple destructuring - SR-4738

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170601/8fef7925/attachment.html>

More information about the swift-evolution mailing list