<div dir="ltr"><div dir="auto"><div><div id="gmail-m_4025242186925874398AppleMailSignature"><br>On 7 Jun 2017, at 18:10, Xiaodi Wu via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br></div><br></div><blockquote type="cite"><div><div><div>On Wed, Jun 7, 2017 at 10:03 Gwendal Roué <<a href="mailto:gwendal.roue@gmail.com" target="_blank">gwendal.roue@gmail.com</a>> wrote:<br></div><div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><blockquote type="cite"><div>Le 7 juin 2017 à 15:52, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>> a écrit :</div><br class="gmail-m_4025242186925874398m_1643076280865659576m_7560201093085690916Apple-interchange-newline"><div><div><div><div class="gmail_quote"><div>Let’s clarify: you just wrote that you have problems with SE-0029, SE-0066, SE-0110, and “before,” did you not?</div></div></div></div></div></blockquote><div><br></div></div></div><div style="word-wrap:break-word"><div><div>WTF? No I did not (citation below)!</div><div><br></div><div><blockquote type="cite"><div style="word-wrap:break-word"></div></blockquote></div></div></div><div style="word-wrap:break-word"><div><div><blockquote type="cite"><div style="word-wrap:break-word"><div>Le 7 juin 2017 à 15:02, Gwendal Roué <<a href="mailto:gwendal.roue@gmail.com" target="_blank">gwendal.roue@gmail.com</a>> a écrit :</div><br class="gmail-m_4025242186925874398m_1643076280865659576m_7560201093085690916Apple-interchange-newline"></div></blockquote></div></div></div><div style="word-wrap:break-word"><div><div><blockquote type="cite"><div style="word-wrap:break-word"><div><div style="word-wrap:break-word"><blockquote type="cite">Le 7 juin 2017 à 14:42, Vladimir.S <<a href="mailto:svabox@gmail.com" target="_blank">svabox@gmail.com</a>> a écrit :<br></blockquote><div><blockquote type="cite"><br class="gmail-m_4025242186925874398m_1643076280865659576m_7560201093085690916Apple-interchange-newline"><div><span style="float:none;display:inline">Gwendal, again, you are proposing to revert not just SE-0110 and SE-0066 but mainly SE-0029 "Remove implicit tuple splat behavior from function applications"</span><br><span style="float:none;display:inline">(</span><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0029-remove-implicit-tuple-splat.md" target="_blank">https://github.com/apple/<wbr>swift-evolution/blob/master/<wbr>proposals/0029-remove-<wbr>implicit-tuple-splat.md</a><span style="float:none;display:inline">)</span><br></div></blockquote><div><br></div>Do you mean that the regressions Stephen and I have shown have been introduced not only by SE-0110, but before SE-0066, and SE-0029?</div></div></div></div></blockquote></div></div></div><div style="word-wrap:break-word"><div><div><blockquote type="cite"><div style="word-wrap:break-word"><div><div style="word-wrap:break-word"></div></div></div></blockquote><div><div style="word-wrap:break-word"><div style="word-wrap:break-word"><div><br></div><div>Your attitude is obnoxious. Enough Swift evolution for me today.</div></div></div></div></div></div></div></blockquote><div><br></div></div></div></div><div><div class="gmail_quote"><div>Please refrain from personal attacks. Are we reading the same sentence? I see that you literally listed three proposals (and “before”) and blamed them for “regressions” that you want to reverse. If that’s not your meaning, what do you mean?</div></div></div></div></blockquote><div><br></div><div>In the conversation you can see that Vladimir stated that proposing to revert this proposal would also mean reverting other previous proposals.</div><div><br></div><div>Gwendal is only asking back if the bug was introduced by the changesets related to those proposals or by the changesets related to SE-0110.</div><div><br></div><div>Asking back is very different from blaming those proposals, or asking for reversal of Swift 3 proposals. SE-0110 may be an obvious extension of the proposed goal, but it is clear that it has been implemented in Swift 4, and that the consequences are derived of those changesets.</div><div><br></div><div>Those "unwanted" consequences can be reverted by temporarily reverting SE-0110, without touching any other previous proposal.</div><div><br></div><div>In no place I see Gwendal asking for full reversal of 5 proposals. He is just voicing something that a lot of app developers and library maintainers are not going to understand in September.</div><div><br></div><div>For example, you can see all the changes needed in RXSwift so that it compiles to Swift 4:</div><div><br></div><div><a href="https://github.com/ReactiveX/RxSwift/pull/1282/commits/915e00fa6d1e59d58cd8c38dd6dc83765fc67fe4">https://github.com/ReactiveX/RxSwift/pull/1282/commits/915e00fa6d1e59d58cd8c38dd6dc83765fc67fe4</a><br></div><div dir="auto"><br></div>I would not want to migrate to Swift 4 an app using such framework.<br><blockquote type="cite"><div><div><div class="gmail_quote"><div>I asked you in my first reply to you, is your view that the distinction itself between (Int, Int) -> Int and ((Int, Int)) -> Int is problematic? If so, this is a very different discussion from seeking solutions to mitigate particular ergonomic issues that arise from the change. However, you have not answered the question.</div></div></div>
</div></blockquote><div><br></div><div>As far as I can see, the bigger usability regressions are caused when using generics, specially in collections and functional utilities. When you specify that type with a tuple, as in Dictionary, then all the related methods start receiving closures receiving tuples.</div><div><br></div><div>Notice that allowing some syntactic sugar on the call site of those closures may not be enough, since you may have stored or passed a closure for customization purposes.</div><div><br></div><div><div>This behavior is so hurtful to functional style programming, that I think either SE-0110 should be reverted, or alternatives like this Susan proposal should be implemented. However, reverting may be safer and faster than adding more new code to the compiler with such short time until Swift 4 release.</div></div><div><br></div><div>Of course that´s the Core team call, if the gains in the compiler code is so great then we'll have to live with this regression. After WWDC I hope that they notify their decision.</div><div><br></div><div>--</div><div>Víctor Pimentel</div></div></div>