<div dir="ltr"><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">&lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
I understand that there are developers who dislike SE-0110&#39;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><br></div><div>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>* concise but obfuscate code ($0.1, ...)</div><div>* 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><br></div><div>Maybe I misunderstood you, but I don&#39;t think this is marginal issue affecting only some &quot;developers that dislike the impact on certain kinds of functional programming&quot;. </div><div><br></div><div>This is a HUGE regression to the usability of all closure with tuple arguments. I&#39;d wager that is the prevailing consensual opinion of anyone who has experienced this issue in practice. <br></div><div><br></div><div>I would go as far as to claim that current implementation of SE-0110 does not conform to the Swift 4&#39;s goal of backwards source compatibility.</div><div> </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><br></div><div>From what I understand our options are quite limited because of tight constraints of Swift 4&#39;s emphasis on backwards source-compatibility and impending release deadline:</div><div><br></div><div>* effectively revert SE-0110 by always using the codepath for Swift 3 compatibility mode</div><div>* implement full tuple destructuring (unexplored issues with syntax and backwards compatibility)</div><div><br></div><div>(Note that Swift 3 didn&#39;t support full tuple destructuring - <a href="https://bugs.swift.org/browse/SR-4738">SR-4738</a>)</div><div><br></div><div>--Pavol</div></div></div></div>