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

[Víctor Pimentel Rodríguez]

On Thu, Jun 8, 2017 at 3:01 PM, Vladimir.S <svabox at gmail.com> wrote:

> On 08.06.2017 12:17, Víctor Pimentel Rodríguez via swift-evolution wrote:
>
>> On Thu, Jun 8, 2017 at 5:15 AM, Susan Cheng via swift-evolution <
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>
>>     Just a thought
>>
>>     if parentheses is important, why the tuples are not?
>>
>>
>> This is stated on the proposal (and not in previous proposals):
>>
>> https://github.com/apple/swift-evolution/blob/master/proposa
>> ls/0110-distingish-single-tuple-arg.md
>>
>>   *
>>
>>     We understand that this may be a departure from the current
>> convention that a set
>>     of parentheses enclosing a single object are considered semantically
>> meaningless,
>>     but it is the most natural way to differentiate between the two
>> situations
>>     described above and would be a clearly-delineated one-time-only
>> exception.
>>
>>
>>     <https://github.com/apple/swift-evolution/blob/master/propos
>> als/0110-distingish-single-tuple-arg.md#impact-on-existing-code>
>>
>> This proposal marks a one-time-only exception, to differentiate the
>> parenthesis needed to enclose a list of closure parameters and the
>> parenthesis needed for tuples. That's adding an exception for implementing
>> a regression.
>>
>> The more I think about it, the more I hate* this proposal.
>>
>> * Well, not _hate_, let's say slightly dislike :P
>>
>
> Please look here:
> https://github.com/apple/swift-evolution/blob/master/proposa
> ls/0066-standardize-function-type-syntax.md
>
> into "Proposed solution" section:
>
> Parentheses will be required in function types. Examples:
>
> Int -> Int           // error
> (Int) -> Int         // function from Int to Int
> ((Int)) -> Int       // also function from Int to Int
>
> Int, Int -> Int      // error
> (Int, Int) -> Int    // function from Int and Int to Int
> ((Int, Int)) -> Int  // function from tuple (Int, Int) to Int
>
> let f: () -> Int     // function with no parameters
> let g: (()) -> Int   // function taking a single () parameter
> let h: ((())) -> Int // function taking a single () parameter
>
> f();   g(()); h(())  // correct
> f(()); g();   h()    // errors
>
> Do you also hate* SE-0066?


I'm certainly not a fan, although I must say that it's funny to me to think
of the usefulness of a closure that only accepts a single parameter of type
"()", and how important it's to be able to model it. It was beautiful to me
how tuples and closure arguments were interchangeable, and I hope that some
day that feature will be back.

I'm also not a fan of SE-0029, the original proposal that removed tuple
splat and linked from SE-0110. I'm fine if it was better for the compiler
to remove that hacky implementation, but that proposal certainly has some
disdain for implicit tuple splat:

> This doesn’t seem like a positive contribution - this seems like a
"clever" feature, not a practical one.

And going back to SE-0110, I dislike this part too:

> The current behavior violates the principle of least surprise

People seems to get more surprised when you migrate some perfectly
reasonable code and have to use an intermediate tuple to achieve the same
effect as the code example in SE-0110 shows.

After rereading the proposals the motivation sections read more like "we
don't like this feature and it's useless" more than "we don't like this
implementation and it's dragging us". Looking at the final implementation
of this proposal (the third one!), I don't think the resulting code is
easier to maintain, actually the Swift 4 mode seems more complex:

https://github.com/apple/swift/pull/6133/files

I'm sorry, but I like this feature. Apart from Dictionary and similar, I'm
really going to miss being able to model every type of closure with the
type (T) -> U.

-- 
Víctor Pimentel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170608/d1d461a7/attachment.html>