[swift-evolution] [Proposal][Discussion] Deprecate Tuple Shuffles
xiaodi.wu at gmail.com
Fri May 5 00:59:32 CDT 2017
On Fri, May 5, 2017 at 12:42 AM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
> On Fri, May 5, 2017 at 00:17 Robert Widmann <devteam.codafi at gmail.com>
>> On the contrary, this is precisely what it means to deprecate tuple
>> shuffles. You can’t map common parlance onto this term; the proposal and
>> the Twitter thread weren’t merely about reordering arguments.
> Let's be clear: _all_ of your examples of "shuffles" in the proposal
> involve reordering. You defined a tuple shuffle as such: "an undocumented
> feature of Swift in which one can re-order the indices of a tuple...." If
> you intend to propose a broader change, it is grossly misleading to write
> it up in this way.
> but it is entirely another ballgame to remove labels from tuple patterns
>> It’s really not. Let me demonstrate:
>> To be clear, are you proposing the prohibition of *adding or removing*
>>> labels as well? A previous discussion on tuple shuffling on this list saw
>>> consensus that assigning a value of type (label1: T, label2: U) to a
>>> variable of type (T, U) and vice versa should absolutely be supported,
>>> whether or not reordering is permitted.
>> I am not proposing any changes to switching parameter labels through
>> well-typed re-assignments. This is absolutely still going to be allowed:
>> var z : (Int, Int) = (0, 0)
>> var w : (x : Int, y : Int) = (5, 10)
>> z = w
>> w = z
>> This is modeled internally with a tuple shuffle, but not the kind of
>> shuffle I’m interested in banning. It’s a far simpler kind of
> What is your proposed behavior for the following code?
> let x: (r: Int, g: Int, b: Int, a: Int) = (255, 255, 255, 0)
> let y: (a: Int, r: Int, g: Int, b: Int) = x
> print(y.a) // currently, prints "0"
> Either you are proposing only to remove labels from tuple patterns, which
> does not at all prohibit reordering, or you are proposing to prohibit
> reordering, in which case this code has an error--or it doesn't and you've
> instead _silently_ changed the behavior of existing code. One can live with
> warnings and even errors, but a silent change to existing code is the stuff
> of nightmares, and I would be strongly opposed to that.
>> And how about *restating* existing labels without any adding or removing?
>>> To be clear:
>>> let (partialValue: v, overflow: o) = 42.addingReportingOverflow(42)
>>> ...involves absolutely no changes in labels whatsoever. The return type
>>> is (partialValue: Int, overflow: ArithmeticOverflow).
>> That, however, is a kind of shuffle I intend to deprecate here. This
>> kind of pattern is subject to the “arcane syntax” part of the proposal.
>>> Either one of these scenarios is commonly used, and it is astonishing to
>>> me that they would be eliminated.
>> Do you have proof of that claim? I have never seen the relevant kinds of
>> tuple shuffle used before, and I doubt you have either before today.
> Huh? I use it pervasively. Currently, writing out labels during
> destructuring guarantees that, even if I've incorrectly memorized the order
> of the values in a tuple, the tuple is still destructured as I expect. And
> if reordering were not a feature of Swift, I would still write out these
> labels. In that case, it would be a static assertion that destructuring is
> happening in the expected order. That is, if I try to destructure a tuple
> of type (r: Int, g: Int, b: Int, a: Int) and accidentally write 'let (a:
> alpha, r: _, g: green, b: _) = ...', I'd get an error and find my mistake
> at compile time.
> The whole point of having labels in the first place is clarity at the
> point of use. Just as SE-0111 will need revision because it removed a key
> documentation use for argument labels, forbidding labels in tuple patterns
> would make the same mistake for tuples.
I should add, it boggles the mind that you would claim that people will
have never heard of this before today. It's been discussed _on this very
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution