<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">I vote to revert it to current behavior. Then we can take time to come up with the correct answer for future Swift.<div class=""><br class=""></div><div class="">If we don’t revert and then end up changing it again later, we will break everybody’s code twice...<br class=""><div class=""><br class=""></div><div class="">Thanks,</div><div class="">Jon<br class=""><div class=""><br class=""></div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jun 1, 2017, at 2:39 PM, Pavol Vaskovic via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote">On Thu, Jun 1, 2017 at 8:52 PM, John McCall via swift-evolution <span dir="ltr" class=""><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br class="">
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. </blockquote><div class=""><br class=""></div><div class="">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:</div><div class="">* concise but obfuscate code ($0.1, ...)</div><div class="">* 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)</div><div class=""><br class=""></div><div class="">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". </div><div class=""><br class=""></div><div class="">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. <br class=""></div><div class=""><br class=""></div><div class="">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.</div><div class=""> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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.</blockquote><div class=""><br class=""></div><div class="">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:</div><div class=""><br class=""></div><div class="">* effectively revert SE-0110 by always using the codepath for Swift 3 compatibility mode</div><div class="">* implement full tuple destructuring (unexplored issues with syntax and backwards compatibility)</div><div class=""><br class=""></div><div class="">(Note that Swift 3 didn't support full tuple destructuring - <a href="https://bugs.swift.org/browse/SR-4738" class="">SR-4738</a>)</div><div class=""><br class=""></div><div class="">--Pavol</div></div></div></div>
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></div></div></div></body></html>