<div style="white-space:pre-wrap">Yes. See earlier in the discussion about the Unicode confusables list. The security issues that arise from confusable URLs aren&#39;t the same as those for identifiers in Swift, and I think the short version of the previous discussion is that prohibiting the use of Greek nu and mathematical bold italic v, for instance, isn&#39;t necessary for security.<br><br>Thus, we&#39;re working off of a different Unicode recommendation specifically drawn up for identifier normalization, which does not involve forbidding confusables.<br></div><br><div class="gmail_quote"><div dir="ltr">On Tue, Jun 28, 2016 at 14:43 Russ Bishop via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Doesn&#39;t Unicode have a standard for this that specified which characters are look-alikes?<br>
<br>
Russ<br>
<br>
&gt; On Jun 21, 2016, at 7:48 AM, Vladimir.S via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; wrote:<br>
&gt;<br>
&gt;<br>
&gt;&gt; On 21.06.2016 7:37, Charlie Monroe via swift-evolution wrote:<br>
&gt;&gt;<br>
&gt;&gt;&gt; On Jun 21, 2016, at 2:23 AM, Brent Royal-Gordon via swift-evolution<br>
&gt;&gt;&gt; &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; wrote:<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; Perhaps stupid but: why was Swift designed to accept most Unicode<br>
&gt;&gt;&gt;&gt; characters in identifier names? Wouldn’t it be simpler to go back to<br>
&gt;&gt;&gt;&gt; a model where only standard ascii characters are accepted in<br>
&gt;&gt;&gt;&gt; identifier names?<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; I assume it has something to do with the fact that 94.6% of the<br>
&gt;&gt;&gt; world&#39;s population speak a first language which is not English. That<br>
&gt;&gt;&gt; outweighs the inconvenience for Anglo developers, IMHO.<br>
&gt;&gt;<br>
&gt;&gt; Yes, but the SDKs (frameworks, system libraries) are all in English,<br>
&gt;&gt; including Swift standard library. I remember a few languages attempting<br>
&gt;&gt; localized versions for kids to study better, failing terribly because<br>
&gt;&gt; you learned something that had a very very limited use.<br>
&gt;<br>
&gt; Support Charlie&#39;s opinion. For me (as non-native English speaker) non-ASCII characters in identifiers had no sense, even when I start to tech the programming when I was a child. Expressions composed from identifiers written in my native language is not near correct sentences.<br>
&gt;<br>
&gt; Even more, we still have all other parts of language in English - for-while-guard-let-var-func etc..<br>
&gt;<br>
&gt;&gt;<br>
&gt;&gt; When it comes to maintaining code, using localized identifier names is a<br>
&gt;&gt; bad practice since anyone outside that country coming to the code can&#39;t<br>
&gt;&gt; really use it. I personally can&#39;t imagine coming to maintain Swift code<br>
&gt;&gt; with identifiers in Chinese, Japanese, Arabic, ...<br>
&gt;&gt;<br>
&gt;&gt; While the feature of non-ASCII characters being allowed as identifiers<br>
&gt;&gt; (which was held up high with Apple giving emoji examples) may seem cool,<br>
&gt;&gt; I can only see this helpful in the future, given a different keyboard<br>
&gt;&gt; layout (as someone has pointed out some time ago here), to introduce<br>
&gt;&gt; one-character operators that would be otherwise impossible. But if<br>
&gt;&gt; someone came to me with a code where a variable would be an emoji of a<br>
&gt;&gt; dog, he&#39;d get fired on the spot.<br>
&gt;<br>
&gt; Yes, but I don&#39;t believe Apple will accept limiting of character set for identifiers to ASCII *after* these presentations with emoji of a dog ;-)<br>
&gt;<br>
&gt;&gt;<br>
&gt;&gt; I&#39;d personally vote to keep the zero-width-joiner characters forbidden<br>
&gt;&gt; within the code outside of string literals (where they may make sense).<br>
&gt;&gt; I agree that this can be easily solved by linters, but: I think this<br>
&gt;&gt; particular set of characters should be restricted by the language<br>
&gt;&gt; itself, since it&#39;s something easily omittable during code review and<br>
&gt;&gt; given the upcoming package manager, this can lead to a hard-to-find<br>
&gt;&gt; malware being distributed among developers who include these packages<br>
&gt;&gt; within their projects - since you usually do not run a linter on a 3rd<br>
&gt;&gt; party code.<br>
&gt;<br>
&gt; I also think the main problem that could be caused by such tricks with zero-width-joiner or right-to-left-markers is injecting some malware code into sources in github, in package manager *or* even just in  code snippet on web page(so you copy-pasted it to your source). Right now I don&#39;t know exact method to implement such malware code, but I believe this vulnerability could be used some day.<br>
&gt;<br>
&gt; Btw, regarding the package manager. Will we have any protection from Typosquatting ? <a href="http://incolumitas.com/2016/06/08/typosquatting-package-managers/#typosquatting-package-managers" rel="noreferrer" target="_blank">http://incolumitas.com/2016/06/08/typosquatting-package-managers/#typosquatting-package-managers</a><br>
&gt;<br>
&gt;&gt;<br>
&gt;&gt; As for the confusables - this depends a lot on the rendering and what<br>
&gt;&gt; font you have set. I&#39;ve tried  𝛎 → v with current Xcode and it looks<br>
&gt;&gt; really different, mostly when you use a fixed-space font which usually<br>
&gt;&gt; doesn&#39;t have non-ASCII characters which are then rendered using a<br>
&gt;&gt; different font, making the distinction easy to spot.<br>
&gt;<br>
&gt; In Russian we have these chars :<br>
&gt; у к е г х а р о с ь<br>
&gt; which are similar to english:<br>
&gt; y k e r x a p o c b<br>
&gt;<br>
&gt; So you most likely can&#39;t differ `рос` and `poc` , `хае` and `xae` etc<br>
&gt;<br>
&gt; I don&#39;t think compiler should somehow decide if one non-English letter is looks like another English letter. But don&#39;t see any other method to protect myself other than using lints/checking tools for 3rd party code also.<br>
&gt;<br>
&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Honestly, this seems to me like a concern for linters and security<br>
&gt;&gt;&gt; auditing tools, not for the compiler. Swift identifiers are<br>
&gt;&gt;&gt; case-sensitive; I see no reason they shouldn&#39;t be script-sensitive or<br>
&gt;&gt;&gt; zero-width-joiner-sensitive. (Though basic Unicode normalization seems<br>
&gt;&gt;&gt; like a good idea, since differently-normalized strings are `==`<br>
&gt;&gt;&gt; anyway.)<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; -- Brent Royal-Gordon Architechies<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; _______________________________________________ swift-evolution<br>
&gt;&gt;&gt; mailing list <a href="mailto:swift-evolution@swift.org" target="_blank">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;<br>
&gt;&gt; _______________________________________________ swift-evolution mailing<br>
&gt;&gt; list <a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
&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;<br>
&gt; _______________________________________________<br>
&gt; swift-evolution mailing list<br>
&gt; <a href="mailto:swift-evolution@swift.org" target="_blank">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>
_______________________________________________<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/mailman/listinfo/swift-evolution</a><br>
</blockquote></div>