Thanks Xiaodi. That’s a relief to know.
> On Jun 23, 2016, at 3:32 PM, Xiaodi Wu <[email protected]> wrote: > > FWIW, Josh's example would be fixed whether we prohibit or ignore invisible > characters, but there are other potential strings for which prohibition would > be more secure. > > On Thu, Jun 23, 2016 at 15:27 James Hillhouse <[email protected] > <mailto:[email protected]>> wrote: > +1 on this. Josh Wisenbaker’s example says enough. Yikes! > >> On Jun 23, 2016, at 3:18 PM, David Sweeris via swift-evolution >> <[email protected] <mailto:[email protected]>> wrote: >> >> +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] <mailto:[email protected]>> wrote: >> >>> On Thu, Jun 23, 2016 at 2:54 PM, João Pinheiro <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> > On 23 Jun 2016, at 20:43, Xiaodi Wu <[email protected] >>> > <mailto:[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] <mailto:[email protected]> >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] <mailto:[email protected]> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution> >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
