<div><br><div class="gmail_quote"><div>On Wed, Jun 7, 2017 at 14:13 Víctor Pimentel Rodríguez <<a href="mailto:vpimentel@tuenti.com">vpimentel@tuenti.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div><div id="m_83922729385446969gmail-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="m_83922729385446969gmail-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="m_83922729385446969gmail-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="m_83922729385446969gmail-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/swift-evolution/blob/master/proposals/0029-remove-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></div><div><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.</div></div></div></blockquote><div><br></div><div>See, I read that sentence as a rhetorical question, intensifying his claim of not merely one but all of these proposals being regressions. If that’s is not what’s intended, that is fine, but he is certainly capable of replying to my question about his meaning without declaring me to be ‘obnoxious.’</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div>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" target="_blank">https://github.com/ReactiveX/RxSwift/pull/1282/commits/915e00fa6d1e59d58cd8c38dd6dc83765fc67fe4</a><br></div><div><br></div>I would not want to migrate to Swift 4 an app using such framework.</div></div><div><div><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></div><div><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></div></blockquote><div><br></div><div>Can you illustrate this with an example? I’m not sure I understand what you’re getting at here.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><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.</div></div></div></div></blockquote><div><br></div><div>To be clear, what you and Gwendal are objecting to is the loss of tuple splatting, is it not? Again, SE-0110 is only the final piece; SE-0029 is what removed implicit tuple splatting. As that proposal said, a properly designed explicit tuple splatting can be considered if there’s demand, and it was understood that removing this functionality would be a regression and nonetheless the decision for removal was still deliberately undertaken. Re-reading that proposal, the rationale was that it never worked correctly to begin with, and the barrier for bringing it back is that it requires considerable effort to design and implement the feature correctly.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div><div>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>
</blockquote></div></div>