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

Susan Cheng susan.doggie at gmail.com
Tue Jun 6 22:21:42 CDT 2017


 [(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/c62545fb/attachment.html>


More information about the swift-evolution mailing list