<div dir="ltr">On Mon, May 8, 2017 at 3:35 AM, André Videla <span dir="ltr">&lt;<a href="mailto:andre.videla@gmail.com" target="_blank">andre.videla@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">By the way, it seems that the only way to get rid of this clever puzzle is to enforce uppercase for the first letter of type identifiers and lower case for values identifiers.</div></blockquote><div><br></div><div>Why do you feel this clever puzzle needs to be eliminated? Do you have any evidence that this shows up in real-world code? As I said before, my analysis is that it will only be found in code if the writer is intentionally trying to torture his or her reader, which is a fruitless issue to prevent.</div><div><br></div><div>The convention of using uppercase only for the first letter of types is already well observed. However, there are legitimate reasons why someone may choose to name a member with uppercase. For instance, I have had to use the name `T` at one point, because I was modeling something where `t` means a totally different thing. Mathematical constants tend to differ based on case. Consider also C interop issues. Finally, this distinction becomes meaningless in languages without case; the same could not be enforced for CJK variable names and type names, for example. However, it is possible to warn when a variable name shadows a type, and this could be useful. But, before we go designing anything in this area, again, as I&#39;ve already written in this thread, there will already be many compiler warnings and errors if someone makes this mistake unintentionally; Robert has presented a clever puzzle, but it is confusing only because he has deliberately designed it to be a puzzle.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_extra"><div class="gmail_quote"><div><div class="h5">2017-05-08 10:24 GMT+02:00 Adrian Zubarev via swift-evolution <span dir="ltr">&lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt;</span>:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><div style="word-wrap:break-word"><div class="m_-6548584445903867683m_-5533058024677394570bloop_markdown"><p>I still have to disagree on that. Tuple patterns are not consistent in Swift.</p>

<p>Here is a small proof of my claim:</p>

<pre><code class="m_-6548584445903867683m_-5533058024677394570swift">enum Foo {
     
    case a(b: Int)
}

switch Foo.a(b: 10) {
     
case .a(b: let x):
    print(x)
}

let tuple = (x: 2, y:  20)

switch tuple {
     
case (x: let a, y: let b):
    print(a); print(b)
}

(x: let a, y: let b): (x: Int, y: Int) = tuple // Error!!!
</code></pre>

<p>Tuple destructuring only works using the shorthand pattern, which _can_ lead to all those puzzles from the discussion. </p>

<hr>

<p>The shorthand form ‘Is good and beautiful’ (German proverb), but it can do more harm than it should. Personally I would entirely ban the shorthand version unless we’ve got a superior version of it without all these issues.</p>

<hr>

<p>By the way not only tuples are affected by the mentioned puzzle:</p>

<pre><code class="m_-6548584445903867683m_-5533058024677394570swift">enum Foo {
     
    case sum(x: Int, y: Int)
}

switch Foo.sum(x: 3, y: 1) {
     
case let .sum(x: Int, y: Double):
    print(Int + Double) // prints 4
}
</code></pre>

<p></p></div><div class="m_-6548584445903867683m_-5533058024677394570bloop_original_html"><span><div id="m_-6548584445903867683m_-5533058024677394570bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto"><br></div> <br> <div id="m_-6548584445903867683m_-5533058024677394570bloop_sign_1494231335461091072" class="m_-6548584445903867683m_-5533058024677394570bloop_sign"><div style="font-family:helvetica,arial;font-size:13px">-- <br>Adrian Zubarev<br>Sent with Airmail</div></div> <br></span><span><p class="m_-6548584445903867683m_-5533058024677394570airmail_on">Am 8. Mai 2017 um 09:28:52, Xiaodi Wu via swift-evolution (<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>) schrieb:</p> <blockquote type="cite" class="m_-6548584445903867683m_-5533058024677394570clean_bq"><span><div><span style="color:rgb(0,0,0);font-family:helvetica;font-size:13px;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;display:inline!important;float:none">But, in any case, with respect to consistency with the rest of the language, tuple patterns with labels are *supremely* consistent.</span></div></span></blockquote></span></div><div class="m_-6548584445903867683m_-5533058024677394570bloop_markdown"><p></p></div></div><br></div></div><span class="">______________________________<wbr>_________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailma<wbr>n/listinfo/swift-evolution</a><br>
<br></span></blockquote></div><br></div>
</blockquote></div><br></div></div>