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

[Susan Cheng]

I don't think it's a roll back change.

The proposal is not proposing allow to reorder the parameters by using the
tuple or implicit tuple splat to fit the function parameters.
It's just clarify the relationship of tuples and argument lists.

as the grammar of Swift 3, it's allowed wrapping the argument with a single
tuple to a function with two argument.

[(1, 2)].map(+)

and SE-0110 is the proposal make the distinguished and not allowed this
line of code.

although we fix the compiler to accept the destructuring of tuples

[(1, 2)].map({ ((lhs, rhs)) in lhs + rhs })

it's not accepting the code of [(1, 2)].map(+) which the operator + are not
function with accepting the tuple of two elements.

the only way we can thought is that the arguments with single tuple is
flattened and it's most compatible with Swift 3.

2017-06-07 13:05 GMT+08:00 Xiaodi Wu <xiaodi.wu at gmail.com>:

> This is not what was meant during discussion about re-evaluating SE-0110.
> Tuples already behave as described, but function argument lists are not
> tuples and have not been for a very long time: see SE-0029, SE-0066.
>
> Also, consider SE-0046, which makes possible labels in single-argument
> argument lists (not possible in tuples), and SE-0060, which prohibits
> arbitrary reordering (although still possible in tuples). This is to say
> that the whole direction of Swift since version 2 has been to erase the
> historical relationship between tuples and argument lists.
>
> The question is how to accommodate some common use cases for destructuring
> as a matter of syntactic sugar after having carefully distinguished
> argument lists and tuples in the compiler, which is a given, not how to
> roll back a change that was settled in 2011, by Chris’s telling.
>
> On Tue, Jun 6, 2017 at 23:14 Susan Cheng via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>>
>> func add2(_ pair: (Int, Int)) -> Int {
>>     return pair.0 + pair.1
>> }
>>
>> consider the follows
>>
>> let _add2 =  add2     // add2 have the typeof `((Int, Int)) -> Int`, it
>> should flatten to `(Int, Int) -> Int`
>>
>> so these two lines are also acceptable
>> [(1, 2)].map(add1)
>> [(1, 2)].map(add2)
>>
>> this proposal is not just changing the behaviour of closure, this
>> proposal also changing the tuple type
>>
>> (((Int, Int)))   flatten to   (Int, Int)
>> (Int, (((Int, Int))), Int)   flatten to   (Int, (Int, Int), Int)
>>
>>
>> 2017-06-07 12:03 GMT+08:00 Stephen Celis <stephen.celis at gmail.com>:
>>
>>> The inline cases make sense to me, but my concern for ambiguity are
>>> because we can define both of these functions:
>>>
>>>     func add1(_ x: Int, _ y: Int) -> Int {
>>>       return x + y
>>>     }
>>>     func add2(_ pair: (Int, Int)) -> Int {
>>>       return pair.0 + pair.1
>>>     }
>>>
>>>     // What's the behavior here?
>>>     [(1, 2)].map(add1)
>>>     [(1, 2)].map(add2)
>>>
>>> What comes to mind, though, is, Swift already prevents single-element
>>> tuples, so why not prevent functions that take a single tuple as the only
>>> argument?
>>>
>>> Swift could provide a fix-it for functions that take single tuples and
>>> say: "Swift functions cannot take a single tuple. Please write a function
>>> that takes as many arguments as the tuple specified."
>>>
>>> Considering the fact that Swift generally operates in a multi-argument
>>> world, and given that functions taking a single tuple are the minority, I
>>> think this would be a good way to move forward.
>>>
>>> Stephen
>>>
>>> > On Jun 6, 2017, at 11:21 PM, Susan Cheng <susan.doggie at gmail.com>
>>> wrote:
>>> >
>>> >  [(1, 2)].map({ x, y in x + y })  // this line is correct
>>> >  [(1, 2)].map({ tuple in tuple.0 + tuple.1 })  // this line should not
>>> accepted
>>> >
>>> > or
>>> >
>>> >  [(1, 2)].map({ $0 + $1 })  // this line is correct
>>> >  [(1, 2)].map({ $0.0 + $0.1 })  // this line should not accepted
>>> >
>>> > it's because `((Int, Int)) -> Int` always flatten to `(Int, Int) ->
>>> Int`
>>> > so, it should only accept the function with two arguments
>>> >
>>> >
>>> >
>>> > 2017-06-07 11:07 GMT+08:00 Stephen Celis <stephen.celis at gmail.com>:
>>> > I like this a lot, but how do we solve for the function case?
>>> >
>>> >     func add(_ x: Int, _ y: Int) -> Int {
>>> >       return x + y
>>> >     }
>>> >     [(1, 2)].map(add)
>>> >
>>> > Where does `map` with a function of `((Int, Int)) -> Int` fit in?
>>> >
>>> > > On Jun 6, 2017, at 10:15 PM, Susan Cheng via swift-evolution <
>>> swift-evolution at swift.org> wrote:
>>> > >
>>> > > Introduction
>>> > >
>>> > >
>>> > > Because the painful of SE-0110, here is a proposal to clarify the
>>> tuple syntax.
>>> > >
>>> > > Proposed solution
>>> > >
>>> > > 1. single element tuple always be flattened
>>> > >
>>> > > let tuple1: (((Int))) = 0  // TypeOf(tuple1) == Int
>>> > >
>>> > > let tuple2: ((((Int))), Int) = (0, 0)  // TypeOf(tuple2) == (Int,
>>> Int)
>>> > >
>>> > > 2. function arguments list also consider as a tuple, which means the
>>> function that accept a single tuple should always be flattened.
>>> > >
>>> > > let fn1: (Int, Int) -> Void = { _, _ in }
>>> > >
>>> > > let fn2: ((Int, Int)) -> Void = { _, _ in }  // always flattened
>>> > >
>>> > > let fn3: (Int, Int) -> Void = { _ in }  // not allowed, here are two
>>> arguments
>>> > >
>>> > > let fn4: ((Int, Int)) -> Void = { _ in }  // not allowed, here are
>>> two arguments
>>> > >
>>> > > _______________________________________________
>>> > > swift-evolution mailing list
>>> > > swift-evolution at swift.org
>>> > > https://lists.swift.org/mailman/listinfo/swift-evolution
>>> >
>>> >
>>>
>>>
>> _______________________________________________
>> 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/29cb0166/attachment.html>