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

[Xiaodi Wu]

On Wed, Jun 7, 2017 at 14:13 Víctor Pimentel Rodríguez <vpimentel at tuenti.com>
wrote:

>
> On 7 Jun 2017, at 18:10, Xiaodi Wu via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> On Wed, Jun 7, 2017 at 10:03 Gwendal Roué <gwendal.roue at gmail.com> wrote:
>
>> Le 7 juin 2017 à 15:52, Xiaodi Wu <xiaodi.wu at gmail.com> 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é <gwendal.roue at gmail.com> a écrit :
>>
>> Le 7 juin 2017 à 14:42, Vladimir.S <svabox at gmail.com> 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.
>

See, I read that sentence as a rhetorical question, intensifying his claim
of not merely one but all of these proposals being regressions. If that’s
is not what’s intended, that is fine, but he is certainly capable of
replying to my question about his meaning without declaring me to be
‘obnoxious.’

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

Can you illustrate this with an example? I’m not sure I understand what
you’re getting at here.

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

To be clear, what you and Gwendal are objecting to is the loss of tuple
splatting, is it not? Again, SE-0110 is only the final piece; SE-0029 is
what removed implicit tuple splatting. As that proposal said, a properly
designed explicit tuple splatting can be considered if there’s demand, and
it was understood that removing this functionality would be a regression
and nonetheless the decision for removal was still deliberately undertaken.
Re-reading that proposal, the rationale was that it never worked correctly
to begin with, and the barrier for bringing it back is that it requires
considerable effort to design and implement the feature correctly.

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170607/360da1a4/attachment.html>