[swift-evolution] Prohibit invisible characters in identifier names

[John McCall]

> On Jun 20, 2016, at 7:07 PM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
> On Mon, Jun 20, 2016 at 8:58 PM, John McCall via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> On Jun 20, 2016, at 5:22 PM, Jordan Rose via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> IIRC, some languages require zero-width joiners (though not zero-width spaces, which are distinct) to properly encode some of their characters. I'd be very leery of having Swift land on a model where identifiers can be used with some languages and not others; that smacks of ethnocentrism.
> 
> None of those languages require zero-width characters between two Latin letters, or between a Latin letter and an Arabic numeral, or at the end of a word.  Since standard / system APIs will (barring some radical shift) use those code points exclusively, it's justifiable to give them some special attention.
> 
> Although the practical implementation may need to be more limited in scope, the general principle doesn't need to privilege Latin letters and Arabic numerals. If, in any context, the presence or absence of a zero-width glyph cannot possibly be distinguished by a human reading the text, then the compiler should also be indifferent to its presence or absence (or, alternatively, its presence should be a compile-time error).

Sure, that's obvious.  Jordan was observing that the simplest way to enforce that, banning such characters from identifiers completely, would still interfere with some languages, and I was pointing out that just doing enough to protect English would get most of the practical value because it would protect every use of the system and standard library.  A program would then only become attackable in this specific way for its own identifiers using non-Latin characters.

All that said, I'm not convinced that this is worthwhile; the identifier-similarity problem in Unicode is much broader than just invisible characters.  In fact, Swift still doesn't canonicalize identifiers, so canonically equivalent compositions of the same glyph will actually produce different names.  So unless we're going to fix that and then ban all sorts of things that are known to generally be represented with a confusable glyph in a typical fixed-width font (like the mathematical alphabets), this is just a problem that will always exist in some form.

John.

> 
>  
> John.
> 
>> 
>> Jordan
>> 
>> 
>>> On Jun 20, 2016, at 10:51, João Pinheiro via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>> 
>>> Recently there has been a screenshot going around Twitter about C++ allowing zero-width spaces in variable names. Swift also suffers from this problem which can be abused to create ambiguous, misleading, and potentially obfuscate nefarious code.
>>> 
>>> I would like to propose a change to prohibit the use of invisible characters in identifier names.
>>> 
>>> I'm including an example of problematic code at the bottom of this email.
>>> 
>>> Sincerely,
>>> João Pinheiro
>>> 
>>> 
>>> /* The output for this code is:
>>> A
>>> B
>>> C
>>> 1
>>> 2
>>> 3
>>> */
>>> 
>>> func test() { print("A") }
>>> func t​est() { print("B") }
>>> func te​st() { print("C") }
>>> 
>>> let abc = 1
>>> let a​bc = 2
>>> let ab​c = 3
>>> 
>>> test()
>>> t​est()
>>> te​st()
>>> 
>>> print(abc)
>>> print(a​bc)
>>> print(ab​c)
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> 
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160621/e0e67d6d/attachment.html>