[swift-evolution] Proposal: Always flatten the single element tuple
xiaodi.wu at gmail.com
Wed Jun 7 08:11:31 CDT 2017
On Wed, Jun 7, 2017 at 08:02 Gwendal Roué via swift-evolution <
swift-evolution at swift.org> wrote:
> Le 7 juin 2017 à 14:42, Vladimir.S <svabox at gmail.com> 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
> 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
> 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.
> swift-evolution mailing list
> swift-evolution at swift.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution