[swift-evolution] Revisiting SE-0110
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
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
* implement full tuple destructuring (unexplored issues with syntax and
(Note that Swift 3 didn't support full tuple destructuring - SR-4738
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution