I think that the benefits of inclusion from allowing non-ASCII identifiers far outweigh any corner cases this might cause. (Although ironing out and analyzing those is of course important, I don’t think they should be obstacles for implementing this kind of thing.)
Something I’d love to see is translated keywords; shouldn’t be hard with a line in the cargo.toml for a ruidmentary lookup. Again, I’m of the opinion that an imperfect implementation is better than no attempt. I remember reading an article about a professor who translated the keywords in... maybe it was Python? And found their students were much more engaged with the material. Anecdotal, of course, but it’s stuck with me. On Mon, Jun 4, 2018 at 3:53 PM Manish Goregaokar via Unicode < unicode@unicode.org> wrote: > Hi, > > The Rust community is considering > <https://github.com/rust-lang/rfcs/pull/2457> adding non-ascii > identifiers, which follow UAX #31 <http://www.unicode.org/reports/tr31/> > (XID_Start XID_Continue*, with tweaks). The proposal also asks for > identifiers to be treated as equivalent under NFKC. > > Are there any cases where this will lead to inconsistencies? I.e. can the > NFKC of a valid UAX 31 ident be invalid UAX 31? > > (In general, are there other problems folks see with this proposal?) > > > Thanks, > -Manish >