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

[Susan Cheng]

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