[swift-evolution] Revisiting SE-0110

Jonathan Hull jhull at gbis.com
Thu Jun 1 18:53:00 CDT 2017


I vote to revert it to current behavior.  Then we can take time to come up with the correct answer for future Swift.

If we don’t revert and then end up changing it again later, we will break everybody’s code twice...

Thanks,
Jon


> On Jun 1, 2017, at 2:39 PM, Pavol Vaskovic via swift-evolution <swift-evolution at swift.org> wrote:
> 
> On Thu, Jun 1, 2017 at 8:52 PM, John McCall via swift-evolution <swift-evolution at swift.org <mailto: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 argument:
> * 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 <https://bugs.swift.org/browse/SR-4738>)
> 
> --Pavol
> _______________________________________________
> 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/20170601/a208c0cd/attachment.html>


More information about the swift-evolution mailing list