[swift-evolution] [Review] SE-0110: Distinguish between single-tuple and multiple-argument function types

[Vladimir.S]

On 01.07.2016 0:17, Austin Zheng wrote:
> #1 was discussed in this
> thread: http://thread.gmane.org/gmane.comp.lang.swift.evolution/16190.
> According to Chris, "FWIW, Swift 1 supported tuple destructuring in
> parameter lists, and we took it out to simplify the language and eliminate
> special cases."

OK. Got it.

>
> #2 may or may not naturally fall out of fixing the ambiguity. If it
> doesn't, the proposal should definitely add it.

I just think that it is worth to mention how the function type with 
multiply arguments represented currently.

>
> For #3, I would personally take the same approach as when tuple splat and
> explicit currying were removed: it's pretty easy to manually write a
> wrapper to convert between the old form and new form, so explicit bridging
> support isn't worthwhile:
>
> func tupleize<T, U, V, R>(_ original: (T, U, V) -> R) -> ((T, U, V)) -> R {
>   return { x in
>     return original(x.0, x.1, x.2)
>   }
> }
>

Currently there could be a lot of code that relies on current behavior, so 
IMO we should provide a easy way to convert to Swift 3.0. I feel like 
explicit bridging the best solution here.
But from other point of view, Swift 3 is source breaking release anyway and 
one will just need to change tuple to list of parameters (or vice-versa) in 
code to conform to correct type of function.

>
> Best,
> Austin
>
> On Thu, Jun 30, 2016 at 2:02 PM, Vladimir.S via swift-evolution
> <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>
>     Just want to brought some things/questions that was not reflected in
>     proposal and that I think should be mentioned:
>
>     1. Should we be able to have such syntax to de-couple tuple's values in
>     parameter of closure:
>
>     let a : ((Int, Int, Int)) -> Int = { ((x, y, z)) in return x + y + z }
>
>     or only as single parameter
>
>     let a : ((Int, Int, Int)) -> Int = { x in return x.0 + x.1 + x.2 }
>
>
>     2. Currently type of `(Int,Int)->()` is actually `((Int,Int))->()`
>
>     typealias t1 = (Int, Int) -> Int
>     print(t1.self) // ((Int, Int)) -> Int
>
>     the proposal should change this to:
>
>     print(t1.self) // (Int, Int) -> Int
>     where `((Int, Int)) -> Int` means one tuple argument
>
>
>     3. It seems like we should keep the ability to explicitly convert one
>     function type to another as some(many?) code can depend on this current
>     behavior and so we need a way to convert old code to new.
>
>     I.e. I think such construction should work:
>
>     var a : ((Int, Int, Int)) -> Int = { x in return x.0 + x.1 + x.2 }
>
>     a = { x, y, z in return x + y + z} as ((Int, Int, Int)) -> Int
>
>     and
>
>     var b : (Int, Int, Int) -> Int = { x, y, z in return x + y + z }
>
>     b = { x in return x.0 + y.1 + z.2} as (Int, Int, Int) -> Int
>
>
>     Opinions/thoughts?
>
>
>     On 30.06.2016 21:22, Chris Lattner via swift-evolution wrote:
>
>         Hello Swift community,
>
>         The review of "SE-0110: Distinguish between single-tuple and
>         multiple-argument function types" begins now and runs through July
>         4. The proposal is available here:
>
>
>         https://github.com/apple/swift-evolution/blob/master/proposals/0110-distingish-single-tuple-arg.md
>
>         Reviews are an important part of the Swift evolution process. All
>         reviews should be sent to the swift-evolution mailing list at
>
>                 https://lists.swift.org/mailman/listinfo/swift-evolution
>
>         or, if you would like to keep your feedback private, directly to
>         the review manager.
>
>         What goes into a review?
>
>         The goal of the review process is to improve the proposal under
>         review through constructive criticism and contribute to the
>         direction of Swift. When writing your review, here are some
>         questions you might want to answer in your review:
>
>                 * What is your evaluation of the proposal?
>                 * Is the problem being addressed significant enough to
>         warrant a change to Swift?
>                 * Does this proposal fit well with the feel and direction
>         of Swift?
>                 * If you have used other languages or libraries with a
>         similar feature, how do you feel that this proposal compares to those?
>                 * How much effort did you put into your review? A glance, a
>         quick reading, or an in-depth study?
>
>         More information about the Swift evolution process is available at
>
>                 https://github.com/apple/swift-evolution/blob/master/process.md
>
>         Thank you,
>
>         -Chris Lattner
>         Review Manager
>
>
>         _______________________________________________
>         swift-evolution mailing list
>         swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>         https://lists.swift.org/mailman/listinfo/swift-evolution
>
>     _______________________________________________
>     swift-evolution mailing list
>     swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>     https://lists.swift.org/mailman/listinfo/swift-evolution
>
>