+1 I didn't even know there were any invisible characters until this thread came up.
- Dave Sweeris > On Jun 23, 2016, at 15:13, Xiaodi Wu via swift-evolution > <[email protected]> wrote: > >> On Thu, Jun 23, 2016 at 2:54 PM, João Pinheiro <[email protected]> wrote: >> >> > On 23 Jun 2016, at 20:43, Xiaodi Wu <[email protected]> wrote: >> > That's cool, although my preferred solution would be more closely aligned >> > with UAX #31: overtly disallow the glyphs in Table 4 (instead of ignoring >> > them) except in the specific scenarios for ZWJ and ZWNJ identified in UAX >> > #31, then afterwards internally represent the identifier as its >> > NFC-normalized string. >> >> Explicitly disallowing them was my initial idea, but I think it would end up >> being a confusing error for users to encounter. Ignoring the invisible >> characters and leaving it up to a linter to remove them is less likely to >> cause confusion for users. >> >> I'll be sure to describe the alternative of explicitly prohibiting them in >> the proposal though. > > I would strongly urge you to propose explicitly prohibiting them just as UAX > #31 recommends. Their reasoning is that these characters, which include those > that reverse text direction or control joining, can cause one identifier to > be maliciously changed to look like another. If you ignore these characters > instead of prohibiting them, an identifier that visually appears as one > string could in fact be a different one to the compiler. > > Moreover, a compiler error can be made helpful by saying that the offending > character is potentially invisible and it can come with a fix-it to remove > the offending character. I don't think that would confuse the user at all. It > would be more confusing if invisible characters that caused one thing to look > identical to another were silently permitted. > >> >> Sincerely, >> João Pinheiro > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
