<div dir="ltr">On Fri, May 5, 2017 at 12:42 AM, Xiaodi Wu <span dir="ltr">&lt;<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>&gt;</span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span class=""><div>On Fri, May 5, 2017 at 00:17 Robert Widmann &lt;<a href="mailto:devteam.codafi@gmail.com" target="_blank">devteam.codafi@gmail.com</a>&gt; wrote:<br></div></span><div><div class="gmail_quote"><span class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div>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.</div></div></blockquote><div><br></div></span><div>Let&#39;s be clear: _all_ of your examples of &quot;shuffles&quot; in the proposal involve reordering. You defined a tuple shuffle as such: &quot;an undocumented feature of Swift in which one can re-order the indices of a tuple....&quot; If you intend to propose a broader change, it is grossly misleading to write it up in this way.</div><span class=""><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><blockquote type="cite"><div>but it is entirely another ballgame to remove labels from tuple patterns altogether.</div></blockquote><br></div></div><div style="word-wrap:break-word"><div>It’s really not.  Let me demonstrate:</div></div><div style="word-wrap:break-word"><div><br></div><div><blockquote type="cite"><div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">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.</blockquote></div></div></blockquote><br></div></div><div style="word-wrap:break-word"><div>I am not proposing any changes to switching parameter labels through well-typed re-assignments.  This is absolutely still going to be allowed:</div><div><br></div><div><div style="margin:0px;font-size:11px;line-height:normal;font-family:menlo"><div style="margin:0px;line-height:normal"><span style="font-variant-ligatures:no-common-ligatures;color:rgb(186,45,162)">var</span><span style="font-variant-ligatures:no-common-ligatures"> z : (</span><span style="font-variant-ligatures:no-common-ligatures;color:rgb(112,61,170)">Int</span><span style="font-variant-ligatures:no-common-ligatures">, </span><span style="font-variant-ligatures:no-common-ligatures;color:rgb(112,61,170)">Int</span><span style="font-variant-ligatures:no-common-ligatures">) = (</span><span style="font-variant-ligatures:no-common-ligatures;color:rgb(39,42,216)">0</span><span style="font-variant-ligatures:no-common-ligatures">, </span><span style="font-variant-ligatures:no-common-ligatures;color:rgb(39,42,216)">0</span><span style="font-variant-ligatures:no-common-ligatures">)</span></div><div style="margin:0px;line-height:normal"><span style="font-variant-ligatures:no-common-ligatures;color:rgb(186,45,162)">var</span><span style="font-variant-ligatures:no-common-ligatures"> w : (x : </span><span style="font-variant-ligatures:no-common-ligatures;color:rgb(112,61,170)">Int</span><span style="font-variant-ligatures:no-common-ligatures">, y : </span><span style="font-variant-ligatures:no-common-ligatures;color:rgb(112,61,170)">Int</span><span style="font-variant-ligatures:no-common-ligatures">) = (</span><span style="font-variant-ligatures:no-common-ligatures;color:rgb(39,42,216)">5</span><span style="font-variant-ligatures:no-common-ligatures">, </span><span style="font-variant-ligatures:no-common-ligatures;color:rgb(39,42,216)">10</span><span style="font-variant-ligatures:no-common-ligatures">)</span></div><div style="margin:0px;line-height:normal"><span style="font-variant-ligatures:no-common-ligatures">z = w</span></div><div style="margin:0px;line-height:normal"><span style="font-variant-ligatures:no-common-ligatures">w = z</span></div></div></div><div style="margin:0px;font-size:11px;line-height:normal;font-family:menlo"><span style="font-variant-ligatures:no-common-ligatures"><br></span></div><div style="margin:0px;font-size:11px;line-height:normal;font-family:menlo"><div style="font-family:helvetica;font-size:12px">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 </div></div></div></blockquote><div><br></div></span><div><div>What is your proposed behavior for the following code?</div><div><br></div><div>```</div><div>let x: (r: Int, g: Int, b: Int, a: Int) = (255, 255, 255, 0)</div><div>let y: (a: Int, r: Int, g: Int, b: Int) = x</div><div><br></div><div>print(y.a) // currently, prints &quot;0&quot;</div><div>```</div><div><br></div><div>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&#39;t and you&#39;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.</div></div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div style="margin:0px;font-size:11px;line-height:normal;font-family:menlo"><div style="font-family:helvetica;font-size:12px"><br></div><div style="font-family:helvetica;font-size:12px"></div></div></div><div style="word-wrap:break-word"><div style="margin:0px;font-size:11px;line-height:normal;font-family:menlo"><div style="font-family:helvetica;font-size:12px"><blockquote type="cite"><div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">And how about *restating* existing labels without any adding or removing? To be clear:<br><br>```<br>let (partialValue: v, overflow: o) = 42.addingReportingOverflow(42)<br>```<br><br>...involves absolutely no changes in labels whatsoever. The return type is (partialValue: Int, overflow: ArithmeticOverflow).<br></blockquote></div></div></blockquote><div style="font-family:helvetica;font-size:12px"><br></div></div></div></div><div style="word-wrap:break-word"><div style="margin:0px;font-size:11px;line-height:normal;font-family:menlo"><div style="font-family:helvetica;font-size:12px"><div style="font-family:helvetica;font-size:12px">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.</div></div></div></div><div style="word-wrap:break-word"><div style="margin:0px;font-size:11px;line-height:normal;font-family:menlo"><div style="font-family:helvetica;font-size:12px"><br><blockquote type="cite"><div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><br>Either one of these scenarios is commonly used, and it is astonishing to me that they would be eliminated.</blockquote></div></div></blockquote><br></div></div></div><div style="word-wrap:break-word"><div style="margin:0px;font-size:11px;line-height:normal;font-family:menlo"><div style="font-family:helvetica;font-size:12px"></div><div style="font-family:helvetica;font-size:12px">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.</div></div></div></blockquote><div><br></div></span><div>Huh? I use it pervasively. Currently, writing out labels during destructuring guarantees that, even if I&#39;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 &#39;let (a: alpha, r: _, g: green, b: _) = ...&#39;, I&#39;d get an error and find my mistake at compile time.</div><div><br></div><div>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.</div></div></div></div></blockquote><div><br></div><div>I should add, it boggles the mind that you would claim that people will have never heard of this before today. It&#39;s been discussed _on this very list_!</div><div><br></div></div></div></div>