<div dir="ltr"><span style="font-size:12.8px">> Why do you feel this clever puzzle needs to be eliminated?</span><div><span style="font-size:12.8px">I dont feel like it needs to be eliminated.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">> Do you have any evidence that this shows up in real-world code?</span><br></div><div><span style="font-size:12.8px">No.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">> 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.</span></div><div><span style="font-size:12.8px">Other programming language implement the "prime" notation for those cases. Capitalisation is not the only alternative. If you have four variables related to each others you'd have t, t', t'' and t''' . If you use capitals you would use t, T and TT? Tt? T1? the next ones are not very clear.</span><br></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">> Consider also C interop issues.</span><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">I have no idea of the complexity of such a task but there is already some identifiers transformations for Obj-C interop. Maybe this kind of transformation could work for C interop.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">> the same could not be enforced for CJK variable names and type names</span><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">And emoji.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">> R</span><span style="font-size:12.8px">obert has presented a clever puzzle, but it is confusing only because he has deliberately designed it to be a puzzle.</span></div><div><span style="font-size:12.8px">You'd be surprised how many kids playing with Swift in playgrounds create intricate puzzles for themselves unintentionally.</span></div><div><br></div><div class="gmail-yj6qo gmail-ajU" style="font-size:12.8px"></div></div><div class="gmail_extra"><br><div class="gmail_quote">2017-05-08 10:42 GMT+02:00 Xiaodi Wu <span dir="ltr"><<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span class="">On Mon, May 8, 2017 at 3:35 AM, André Videla <span dir="ltr"><<a href="mailto:andre.videla@gmail.com" target="_blank">andre.videla@gmail.com</a>></span> wrote:<br></span><div class="gmail_extra"><div class="gmail_quote"><span class=""><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></span><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'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><div class="h5"><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="m_-5796293640160525756h5">2017-05-08 10:24 GMT+02:00 Adrian Zubarev via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></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="m_-5796293640160525756h5"><div style="word-wrap:break-word"><div class="m_-5796293640160525756m_-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_-5796293640160525756m_-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_-5796293640160525756m_-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_-5796293640160525756m_-6548584445903867683m_-5533058024677394570bloop_original_html"><span><div id="m_-5796293640160525756m_-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_-5796293640160525756m_-6548584445903867683m_-5533058024677394570bloop_sign_1494231335461091072" class="m_-5796293640160525756m_-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_-5796293640160525756m_-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_-5796293640160525756m_-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_-5796293640160525756m_-6548584445903867683m_-5533058024677394570bloop_markdown"><p></p></div></div><br></div></div><span>______________________________<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></div></div><br></div></div>
</blockquote></div><br></div>