<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'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't necessary for security.<br><br>Thus, we'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 <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Doesn't Unicode have a standard for this that specified which characters are look-alikes?<br>
<br>
Russ<br>
<br>
> On Jun 21, 2016, at 7:48 AM, Vladimir.S via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br>
><br>
><br>
>> On 21.06.2016 7:37, Charlie Monroe via swift-evolution wrote:<br>
>><br>
>>> On Jun 21, 2016, at 2:23 AM, Brent Royal-Gordon via swift-evolution<br>
>>> <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br>
>>><br>
>>>> Perhaps stupid but: why was Swift designed to accept most Unicode<br>
>>>> characters in identifier names? Wouldn’t it be simpler to go back to<br>
>>>> a model where only standard ascii characters are accepted in<br>
>>>> identifier names?<br>
>>><br>
>>> I assume it has something to do with the fact that 94.6% of the<br>
>>> world's population speak a first language which is not English. That<br>
>>> outweighs the inconvenience for Anglo developers, IMHO.<br>
>><br>
>> Yes, but the SDKs (frameworks, system libraries) are all in English,<br>
>> including Swift standard library. I remember a few languages attempting<br>
>> localized versions for kids to study better, failing terribly because<br>
>> you learned something that had a very very limited use.<br>
><br>
> Support Charlie'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>
><br>
> Even more, we still have all other parts of language in English - for-while-guard-let-var-func etc..<br>
><br>
>><br>
>> When it comes to maintaining code, using localized identifier names is a<br>
>> bad practice since anyone outside that country coming to the code can't<br>
>> really use it. I personally can't imagine coming to maintain Swift code<br>
>> with identifiers in Chinese, Japanese, Arabic, ...<br>
>><br>
>> While the feature of non-ASCII characters being allowed as identifiers<br>
>> (which was held up high with Apple giving emoji examples) may seem cool,<br>
>> I can only see this helpful in the future, given a different keyboard<br>
>> layout (as someone has pointed out some time ago here), to introduce<br>
>> one-character operators that would be otherwise impossible. But if<br>
>> someone came to me with a code where a variable would be an emoji of a<br>
>> dog, he'd get fired on the spot.<br>
><br>
> Yes, but I don't believe Apple will accept limiting of character set for identifiers to ASCII *after* these presentations with emoji of a dog ;-)<br>
><br>
>><br>
>> I'd personally vote to keep the zero-width-joiner characters forbidden<br>
>> within the code outside of string literals (where they may make sense).<br>
>> I agree that this can be easily solved by linters, but: I think this<br>
>> particular set of characters should be restricted by the language<br>
>> itself, since it's something easily omittable during code review and<br>
>> given the upcoming package manager, this can lead to a hard-to-find<br>
>> malware being distributed among developers who include these packages<br>
>> within their projects - since you usually do not run a linter on a 3rd<br>
>> party code.<br>
><br>
> 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't know exact method to implement such malware code, but I believe this vulnerability could be used some day.<br>
><br>
> 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>
><br>
>><br>
>> As for the confusables - this depends a lot on the rendering and what<br>
>> font you have set. I've tried 𝛎 → v with current Xcode and it looks<br>
>> really different, mostly when you use a fixed-space font which usually<br>
>> doesn't have non-ASCII characters which are then rendered using a<br>
>> different font, making the distinction easy to spot.<br>
><br>
> In Russian we have these chars :<br>
> у к е г х а р о с ь<br>
> which are similar to english:<br>
> y k e r x a p o c b<br>
><br>
> So you most likely can't differ `рос` and `poc` , `хае` and `xae` etc<br>
><br>
> I don't think compiler should somehow decide if one non-English letter is looks like another English letter. But don't see any other method to protect myself other than using lints/checking tools for 3rd party code also.<br>
><br>
>><br>
>>><br>
>>> Honestly, this seems to me like a concern for linters and security<br>
>>> auditing tools, not for the compiler. Swift identifiers are<br>
>>> case-sensitive; I see no reason they shouldn't be script-sensitive or<br>
>>> zero-width-joiner-sensitive. (Though basic Unicode normalization seems<br>
>>> like a good idea, since differently-normalized strings are `==`<br>
>>> anyway.)<br>
>>><br>
>>> -- Brent Royal-Gordon Architechies<br>
>>><br>
>>> _______________________________________________ swift-evolution<br>
>>> mailing list <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>
>><br>
>> _______________________________________________ swift-evolution mailing<br>
>> list <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>
>><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>
_______________________________________________<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>