<div dir="ltr">On Mon, Jun 20, 2016 at 4:44 PM, Dave Abrahams via swift-evolution <span dir="ltr">&lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</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"><span class=""><br>
on Mon Jun 20 2016, Xiaodi Wu &lt;<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>&gt; wrote:<br>
<br>
&gt; On Mon, Jun 20, 2016 at 2:42 PM, João Pinheiro &lt;<a href="mailto:joao@joaopinheiro.org">joao@joaopinheiro.org</a>&gt;<br>
&gt; wrote:<br>
&gt;<br>
&gt;&gt; I agree that treating zero-width spaces as non-existent would be a<br>
&gt;&gt; possible solution, but I think it would make more sense to consider it as<br>
&gt;&gt; white space and thus not admissible in identifier names.<br>
&gt;&gt;<br>
&gt;<br>
&gt; If you treat it like whitespace, then you get interesting behaviors that I<br>
&gt; don&#39;t think you would want. For example, something that looks like `if<br>
&gt; letter...` could be parsed as conditional binding `if let ter...` if I put<br>
&gt; in a zero-width space in the right place.<br>
&gt;<br>
&gt;&gt; I&#39;m not sure of what the best way to handle left-to-right and<br>
&gt;&gt; right-to-left markers would be. Does it make sense to allow mixed text<br>
&gt;&gt; orientation in identifiers?<br>
&gt;&gt;<br>
&gt;<br>
&gt; How do other languages that support Unicode handle these markers in<br>
&gt; identifiers? I&#39;d be interested to know.<br>
&gt;<br>
&gt;&gt; Removing ambiguity between unicode confusables is a much more complicated<br>
&gt;&gt; issue which implies defining a canonical unicode representation for<br>
&gt;&gt; identifiers and a way to resolve them. It would also make it impractical to<br>
&gt;&gt; use certain valid mathematical symbols as identifiers.<br>
&gt;&gt;<br>
&gt;<br>
&gt; Most interesting mathematical symbols are reserved for operators anyway. As<br>
&gt; a result, `x` and the multiplication symbol are not readily confusable in<br>
&gt; most contexts in Swift, and confusable resolution could be built in such a<br>
&gt; way that identifier characters are not regarded as confusable with operator<br>
&gt; characters.<br>
<br>
</span>I&#39;m a little concerned about cases like these:<br>
<br>
1D6CE ; 0076 ;  MA      # ( 𝛎 → v ) MATHEMATICAL BOLD SMALL NU → LATIN SMALL LETTER V  # →ν→<br>
1D6D2 ; 0070 ;  MA      # ( 𝛒 → p ) MATHEMATICAL BOLD SMALL RHO → LATIN SMALL LETTER P # →ρ→<br>
<br>
etc.  Now, one could reasonably argue that using “𝛎” and “v” to mean<br>
different things in the same scope would be bad, but I&#39;m not sure<br>
we really want to accept them as aliases of one another, either.<br></blockquote><div><br></div><div>Yes, that does give me pause. FWIW, though, Greek letters have been known to turn into their lookalike Latin counterparts. For instance, do a Google search for Planck&#39;s equation written as &quot;E = hv&quot; (that &quot;v&quot; is supposed to be lowercase nu). Or consider the abbreviation &quot;XP&quot; for Christ, etymologically uppercase chi and rho (the first two letters of Christ in Greek). (Or relatedly, the erroneous claim that &quot;Xmas&quot; is an attempt to remove Christ out of Christmas.)</div><div><br></div><div>I guess what I&#39;m saying is, if a co-worker named two distinct variables v and nu, I would have a word or two with them... Consider an alternative scenario. I have a Greek keyboard in my keyboard switcher, handy for scientific uses. If I accidentally use Greek uppercase alpha in my code instead of A, this would be essentially impossible to find by eye. Why should the language not elide the invisible distinction?</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5"><br>
&gt;&gt; João Pinheiro<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; On 20 Jun 2016, at 20:23, Xiaodi Wu &lt;<a href="mailto:xiaodi.wu@gmail.com">xiaodi.wu@gmail.com</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; On Mon, Jun 20, 2016 at 2:17 PM, João Pinheiro &lt;<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>&gt;<br>
&gt;&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt;&gt; Nice feature in the IBM Swift Sandbox. Xcode doesn&#39;t display zero-width<br>
&gt;&gt;&gt; spaces either so the identifier names look exactly the same.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; The issue with left-to-right and right-to-left markers is interesting and<br>
&gt;&gt;&gt; has previously been exploited in email phishing attacks.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; It would be possible to highlight invisible characters in Xcode as a<br>
&gt;&gt;&gt; stopgap measure, but that doesn&#39;t solve the problem for developers using<br>
&gt;&gt;&gt; other editors or in other platforms. I think it would be a better idea to<br>
&gt;&gt;&gt; sanitise the set of allowed (or prohibited) characters for identifiers at<br>
&gt;&gt;&gt; the language level.<br>
&gt;&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; This is a potential security problem, but no need try to invent an ad-hoc<br>
&gt;&gt; solution here, particularly one as drastic as prohibiting characters. The<br>
&gt;&gt; same security considerations are applicable elsewhere and there&#39;s a lot of<br>
&gt;&gt; work about Unicode security. See here:<br>
&gt;&gt; <a href="http://www.unicode.org/reports/tr39/" rel="noreferrer" target="_blank">http://www.unicode.org/reports/tr39/</a><br>
&gt;&gt;<br>
&gt;&gt; Unicode maintains a list of &quot;confusable&quot; characters. See here:<br>
&gt;&gt; <a href="http://www.unicode.org/Public/security/latest/confusables.txt" rel="noreferrer" target="_blank">http://www.unicode.org/Public/security/latest/confusables.txt</a><br>
&gt;&gt;<br>
&gt;&gt; It should be sufficient to regard confusables as the same glyph for the<br>
&gt;&gt; purpose of identifier names; zero-width and invisible marks would then be<br>
&gt;&gt; regarded as non-existent, so that `test` and `t[invisible glyph]est` would<br>
&gt;&gt; refer to the same variable.<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt;&gt; Sincerely,<br>
&gt;&gt;&gt; João Pinheiro<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; &gt; On 20 Jun 2016, at 19:26, Vladimir.S &lt;<a href="mailto:svabox@gmail.com">svabox@gmail.com</a>&gt; wrote:<br>
&gt;&gt;&gt; &gt;<br>
&gt;&gt;&gt; &gt; Very interesting.<br>
&gt;&gt;&gt; &gt;<br>
&gt;&gt;&gt; &gt; Btw, IBM Swift Sandbox shows these spaces:<br>
&gt;&gt;&gt; &gt; <a href="https://swiftlang.ng.bluemix.net/" rel="noreferrer" target="_blank">https://swiftlang.ng.bluemix.net/</a><br>
&gt;&gt;&gt; &gt; But my mail client does not - i.e. I saw exactly the same &quot;test&quot;&amp;&quot;abc&quot;<br>
&gt;&gt;&gt; &gt;<br>
&gt;&gt;&gt; &gt; Also, I read about some issues with left-to-right and right-to-left<br>
&gt;&gt;&gt; markers that also somehow change the actual text of source - i.e. you see<br>
&gt;&gt;&gt; one text, but when it compiles - it works not as expected. I.e.<br>
&gt;&gt;&gt; viewer/editor processes these special codes and show you one text, but<br>
&gt;&gt;&gt; compiler treats text in another way.<br>
&gt;&gt;&gt; &gt;<br>
&gt;&gt;&gt; &gt; I believe it is a potential security problem that all unicode chars are<br>
&gt;&gt;&gt; allowed for variables/func names in Swift. IMO We definitely should limit<br>
&gt;&gt;&gt; allowed charset for identifiers in sources.<br>
&gt;&gt;&gt; &gt;<br>
&gt;&gt;&gt; &gt; On 20.06.2016 20:51, João Pinheiro via swift-evolution wrote:<br>
&gt;&gt;&gt; &gt;&gt; Recently there has been a screenshot going around Twitter about C++<br>
&gt;&gt;&gt; allowing zero-width spaces in variable names. Swift also suffers from this<br>
&gt;&gt;&gt; problem which can be abused to create ambiguous, misleading, and<br>
&gt;&gt;&gt; potentially obfuscate nefarious code.<br>
&gt;&gt;&gt; &gt;&gt;<br>
&gt;&gt;&gt; &gt;&gt; I would like to propose a change to prohibit the use of invisible<br>
&gt;&gt;&gt; characters in identifier names.<br>
&gt;&gt;&gt; &gt;&gt;<br>
&gt;&gt;&gt; &gt;&gt; I&#39;m including an example of problematic code at the bottom of this<br>
&gt;&gt;&gt; email.<br>
&gt;&gt;&gt; &gt;&gt;<br>
&gt;&gt;&gt; &gt;&gt; Sincerely,<br>
&gt;&gt;&gt; &gt;&gt; João Pinheiro<br>
&gt;&gt;&gt; &gt;&gt;<br>
&gt;&gt;&gt; &gt;&gt;<br>
&gt;&gt;&gt; &gt;&gt; /* The output for this code is:<br>
&gt;&gt;&gt; &gt;&gt; A<br>
&gt;&gt;&gt; &gt;&gt; B<br>
&gt;&gt;&gt; &gt;&gt; C<br>
&gt;&gt;&gt; &gt;&gt; 1<br>
&gt;&gt;&gt; &gt;&gt; 2<br>
&gt;&gt;&gt; &gt;&gt; 3<br>
&gt;&gt;&gt; &gt;&gt; */<br>
&gt;&gt;&gt; &gt;&gt;<br>
&gt;&gt;&gt; &gt;&gt; func test() { print(&quot;A&quot;) }<br>
&gt;&gt;&gt; &gt;&gt; func t​est() { print(&quot;B&quot;) }<br>
&gt;&gt;&gt; &gt;&gt; func te​st() { print(&quot;C&quot;) }<br>
&gt;&gt;&gt; &gt;&gt;<br>
&gt;&gt;&gt; &gt;&gt; let abc = 1<br>
&gt;&gt;&gt; &gt;&gt; let a​bc = 2<br>
&gt;&gt;&gt; &gt;&gt; let ab​c = 3<br>
&gt;&gt;&gt; &gt;&gt;<br>
&gt;&gt;&gt; &gt;&gt; test()<br>
&gt;&gt;&gt; &gt;&gt; t​est()<br>
&gt;&gt;&gt; &gt;&gt; te​st()<br>
&gt;&gt;&gt; &gt;&gt;<br>
&gt;&gt;&gt; &gt;&gt; print(abc)<br>
&gt;&gt;&gt; &gt;&gt; print(a​bc)<br>
&gt;&gt;&gt; &gt;&gt; print(ab​c)<br>
&gt;&gt;&gt; &gt;&gt; _______________________________________________<br>
&gt;&gt;&gt; &gt;&gt; swift-evolution mailing list<br>
&gt;&gt;&gt; &gt;&gt; <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
&gt;&gt;&gt; &gt;&gt; <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
&gt;&gt;&gt; &gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; _______________________________________________<br>
&gt;&gt;&gt; swift-evolution mailing list<br>
&gt;&gt;&gt; <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
&gt;&gt;&gt; <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
&gt;&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt; _______________________________________________<br>
&gt; swift-evolution mailing list<br>
&gt; <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
&gt; <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
&gt;<br>
<br>
</div></div><span class="HOEnZb"><font color="#888888">--<br>
Dave<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</div></div></blockquote></div><br></div></div>