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

Gwendal Roué gwendal.roue at gmail.com
Wed Jun 7 08:02:45 CDT 2017


> 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 <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). 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170607/f141082a/attachment.html>


More information about the swift-evolution mailing list