[swift-evolution] A path forward on rationalizing unicode identifiers and operators

[Chris Lattner]

> On Oct 2, 2017, at 1:13 AM, Félix Cloutier via swift-evolution <swift-evolution at swift.org> wrote:
> 
> If you tried hard enough, you could probably create a variable that looks like it's shadowing one from an outer scope while it actually isn't, and use the two to confuse readers. This could trick people into thinking that some dangerous/backdoor code is actually good and safe, especially in the open-source world where you can't always trust your contributors.
> 
> On one hand, other than the complexity of telling if two characters are lookalikes, I don't know why Αrray (GREEK CAPITAL LETTER ALPHA) and Array (LATIN CAPITAL LETTER A) should be considered different identifiers. On the other hand, I struggle to imagine the specifics of an exploit that uses that. You'd have to work pretty hard to assemble all the pieces of a backdoor in visually-similar variable names without arousing suspicion.

I don’t think this is something we have to try hard to avoid.  It is true that some characters look similar, particularly in some fonts, but this isn’t new:

   let a1 = 42
   let al = 12
   let b = al + a1 

If there were real code that was maliciously shadowing to try to cause confusion, then you have a more serious problem on your hands than someone accidentally misunderstanding which one to use.

All I’m saying is that we shouldn’t complicate the design to solve this problem (IMO).  If it falls out of the solution somehow (e.g. just disallow invisible characters) then that’s great of course!

-Chris