On Wed, Jun 7, 2017 at 08:02 Gwendal Roué via swift-evolution < [email protected]> wrote:
> Le 7 juin 2017 à 14:42, Vladimir.S <[email protected]> a écrit : > > On 07.06.2017 14:18, Gwendal Roué via swift-evolution wrote: > > Xiaodi, Adrian, you are actively pushing so that something that was > allowed, well compiled (no runtime issue), and covered actual uses cases, > becomes forbidden. Without any developer advantage that would somehow > balance the change. > That's called a regression. > And what's the rationale, already? A sense of compiler aesthetics? Since > when a sense of compiler aesthetics is more valuable than a sense of code > aesthetics? Aren't both supposed to walk together as a pair? > > > 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? > > We can discuss what sugar we can have to have tuple destructuring in > closure and probably some sugar to allow free function of list of arguments > when function of one tuple is required. But I don't see how we can > revisit(and I believe we shouldn't) a number of actively discussed(!) and > accepted proposals and dramatically change direction of Swift evolution > even because of "lacks in terms of user ergonomics" for some period. > > > I don't know. Nobody seemed to care about regressions, so I felt like it > was high time some light was shed on them. > > Btw, please also note that this will not be possible in Swift 4: > Probably this "feature" also was used in Swift 3 code, do we need to > revisit it also? (I believe no) > > > Writing "feature" with ironic quotes is a bad attitude. Some "features" > are the quality of life of developers. > > When proposals are accepted without user feedback, it's reasonable to > expect that users come back after the harm has been done. It has happened > before, for fileprivate (SE-0025). > While SE-0025 was generally regarded as unfortunate, the thousands of emails that followed relitigating it were much, much worse. The removal of implicit tuple splatting, which is *not* SE-0110, was approved on the understanding that it would be a regression until explicit tuple splatting is introduced. This tradeoff was considered and approved. It’s clear that you disagree, but that is not grounds to divert a necessary discussion on mitigating SE-0110 into relitigating something else. This is the case now. Some real bad harm to the language ergonomics has > been done. > > Again, I'm not talking about inner compiler design: feel free to do > whatever is reasonable for Swift and the community. But regressions. > > Gwendal > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
