On 7 Jun 2017, at 18:10, Xiaodi Wu via swift-evolution < [email protected]> wrote:
On Wed, Jun 7, 2017 at 10:03 Gwendal Roué <[email protected]> wrote: > Le 7 juin 2017 à 15:52, Xiaodi Wu <[email protected]> a écrit : > > Let’s clarify: you just wrote that you have problems with SE-0029, > SE-0066, SE-0110, and “before,” did you not? > > > WTF? No I did not (citation below)! > > Le 7 juin 2017 à 15:02, Gwendal Roué <[email protected]> a écrit : > > Le 7 juin 2017 à 14:42, Vladimir.S <[email protected]> a écrit : > > > 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" > (https://github.com/apple/swift-evolution/blob/master/ > proposals/0029-remove-implicit-tuple-splat.md) > > > 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? > > > Your attitude is obnoxious. Enough Swift evolution for me today. > 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? In the conversation you can see that Vladimir stated that proposing to revert this proposal would also mean reverting other previous proposals. 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. 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. Those "unwanted" consequences can be reverted by temporarily reverting SE-0110, without touching any other previous proposal. 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. For example, you can see all the changes needed in RXSwift so that it compiles to Swift 4: https://github.com/ReactiveX/RxSwift/pull/1282/commits/915e00fa6d1e59d58cd8c38dd6dc83765fc67fe4 I would not want to migrate to Swift 4 an app using such framework. 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. 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. 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. 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. 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. -- Víctor Pimentel
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
