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

Austin Zheng austinzheng at gmail.com
Thu Jun 30 16:17:02 CDT 2016


#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."

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

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)
  }
}


Best,
Austin

On Thu, Jun 30, 2016 at 2:02 PM, Vladimir.S via swift-evolution <
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
>> 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/20160630/9da36d20/attachment.html>


More information about the swift-evolution mailing list