<div dir="ltr">On Mon, May 8, 2017 at 3:08 AM, Brent Royal-Gordon <span dir="ltr">&lt;<a href="mailto:brent@architechies.com" target="_blank">brent@architechies.com</a>&gt;</span> wrote:<br><div class="gmail_extra"><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"><div style="word-wrap:break-word"><span class="gmail-"><div><blockquote type="cite"><div>On May 8, 2017, at 12:09 AM, Xiaodi Wu &lt;<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>&gt; wrote:</div><br class="gmail-m_3398540987637101425Apple-interchange-newline"><div><div class="gmail_extra" style="font-family:helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">Highly disagree. Consistency teaches us that variables can come after a colon.</div></div></blockquote><br></div></span><div>But not normally in a declaration.</div><span class="gmail-"><div><br></div><div><blockquote type="cite"><div>On May 8, 2017, at 12:28 AM, Xiaodi Wu &lt;<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>&gt; wrote:</div><br class="gmail-m_3398540987637101425Apple-interchange-newline"><div><span style="float:none;display:inline">Yes, Robert came up with a very clever puzzle. I&#39;ll bet you there are *plenty* of neat puzzles that you can come up with if you start naming your variables `Int` and `Double`.</span></div></blockquote><br></div></span><div>Sure, but how many of them look *so much* like a declaration that, even knowing there&#39;s a puzzle, you still don&#39;t guess what&#39;s going on? Because that was my experience with his &quot;puzzle&quot;.</div></div></blockquote><div><br></div><div>So, then, the puzzle puzzled you.</div><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></div><div>I know that Swift pattern matching is based on the idea that the pattern looks like the code used to construct the value it matches. But in the case of capturing values from labeled paren lists, I think it leads to deeply confusing code. We already knew about the weirdness of `as` in pattern matches, but this is even worse.</div><div><br></div><div>I think we ought to reconsider what we&#39;re doing in this area, and perhaps move more towards a syntax that echoes declaration rather than use. When a piece of syntax *really* looks like it does A, even to experienced users, but it actually does B, that&#39;s a sign that it&#39;s the wrong syntax.</div><span class="gmail-HOEnZb"><font color="#888888"><div></div></font></span></div></blockquote></div><br></div><div class="gmail_extra">Again, if you were to write this piece of code yourself, a whole slew of warnings would tell you unambiguously that it&#39;s B and not A. It would warn you that `Int` and `Double` are never used before you even typed the second line. If you tried to use `x` and `y`, it would error and tell you they&#39;ve not been declared. If the tuple had two homogeneous elements, it would have given an error that you&#39;d redeclared the same variable twice.</div><div class="gmail_extra"><br></div><div class="gmail_extra">And if those aren&#39;t enough, it is possible to add warnings about variable names that shadow type names (which may have broader benefits and is worth consideration) and it is possible to add warnings when labels are used to destructure a tuple that doesn&#39;t come with its own labels.</div><div class="gmail_extra"><br></div><div class="gmail_extra">To demonstrate where the puzzle ended up being very clever, consider this one-liner:</div><div class="gmail_extra"><br></div><div class="gmail_extra">```</div><div class="gmail_extra">print(Int + Double) // Prints &quot;4&quot;.</div><div class="gmail_extra">```</div><div class="gmail_extra"><br></div><div class="gmail_extra">This alone will *really* look like something it is not even to experienced users; it involves no tuples or pattern matching. (Interestingly, without an implementation of the proposal accepted long ago to remove `.self` from the language, one actually cannot make this happen in the following way; in other words, `Int` and `Double` in that context currently _cannot_ be types.)<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">```</div><div class="gmail_extra"><div class="gmail_extra">func + &lt;T, U&gt;(_: T.Type, _: U.Type) -&gt; Int { return 4 }</div><div class="gmail_extra">// However, one must write `Int.self + Double.self`</div></div><div class="gmail_extra">```</div><div class="gmail_extra"><br></div><div class="gmail_extra">But in any case, the original point I was making in response to Robert&#39;s original proposal is that getting rid of tuple shuffles is a topic that&#39;s orthogonal to pattern matching syntax. If you want to redesign all of pattern matching syntax for Swift, that&#39;s a conversation for another day. Just note that `if/for/while let` syntax went through a controversial overhaul for Swift 3, and a proposal to change enum case pattern matching only just got accepted with revisions last month and hasn&#39;t even been implemented yet for Swift 4. This is getting very near access modifiers in terms of churn during every release of Swift.</div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div></div>