[swift-evolution] Proposal: Always flatten the single element tuple

[Xiaodi Wu]

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
> 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
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170607/933d4410/attachment-0001.html>