[swift-evolution] [Proposal][Discussion] Deprecate Tuple Shuffles

Boris Wang kona.ming at gmail.com
Mon May 8 20:52:28 CDT 2017


Thanks, I just got the point:
  This is a war between Smalltalk and the world.

In Smalltalk, function is not a type:
   function's signature include attributes name, but Type not,.
The method Smalltalk treat function, is opposite to the normal method human
see the world.
For exam:
   We just need known someone called Boris Wang, not Boris
Wang(attr1,attr2,....,attr100)

So, the more features we borrowed from the other languages in the world,
the more conflicts triggered.
The more consistent we wanted from Swift, the more conflicts triggered.

Erica Sadun via swift-evolution <swift-evolution at swift.org>于2017年5月9日
周二02:42写道:

>
> On May 4, 2017, at 8:14 PM, Robert Widmann via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> Hi all,
>
> So sorry that this proposal comes so late in the game, but I feel it’s too
> important not to bring it to the attention of the community now.  Attached
> is a proposal to deprecate a language feature many of you will probably
> have never had the chance to use: Tuple Shuffles.  I’ve attached a copy of
> the first draft of the proposal below, but the latest copy can be read on
> Github <https://github.com/apple/swift-evolution/pull/705/files>.
>
> Thanks!
>
> ~Robert Widmann
>
>
> I'm coming into this ridiculously late. Apologies, but I've had family
> responsibilities. I've tried to read through the thread before replaying. I
> hope I have not missed any significant points.
>
> First, I dislike calling this "tuple shuffles". That phrase has an
> existing and useful meaning in the Swift community. It refers to what this
> proposal calls "re-assignment through a tuple pattern". This is what I want
> to keep calling a "tuple shuffle":
>
> `(a, b, c) = (b, c, a)`
>
> I'd rather call the problem space for this proposal "label-led tuple
> assignment" (or something like that) and reserve "tuple shuffle" for
> reordered value reassignment.
>
> Second, I agree with TJ. I dislike that this pattern is legal:
>
> ```
> // Declare using labels
> let rgba: (r: Int, g: Int, b: Int, a: Int) = (255, 255, 255, 0)
>
> // Declare using re-ordered labels
> let argb: (a: Int, r: Int, g: Int, b: Int) = rgba // This is the line I
> have issue with
>
> print(argb.a) // "0"
> ```
>
> I find this usage counter to Swift's philosophy of clarity and simplicity.
> It is sufficiently obscure that I consider it a non-standard use regardless
> of Wux's  Google search results.
>
> Consider the example of Joe Groff's SE-0060 (
> https://github.com/apple/swift-evolution/blob/master/proposals/0060-defaulted-parameter-order.md).
> I believe it's reasonable to mandate that the order of labels in
> declarations be ignored, with the types being compiler-checked.  I'd
> envision that the "correct" behavior should act like this instead:
>
> ```
> // Declare using re-ordered labels
> let argb: (a: Int, r: Int, g: Int, b: Int) = rgba // (Int, Int, Int, Int)
> assigned to (Int, Int, Int, Int)
>
> print(argb.a) // "255"
> ```
>
> This reworking is partially inspired by SE-0111 (
> https://github.com/apple/swift-evolution/blob/master/proposals/0111-remove-arg-label-type-significance.md),
> ensuring that the tuple argument labels are not considered in typing the
> new constant. In fact, this entire proposal might be better named "Removing
> the Ordering Significance of Tuple Argument Labels in Declarations"
>
> -- E
>
> _______________________________________________
> 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/20170509/fc1db11e/attachment.html>


More information about the swift-evolution mailing list