Re: Can NFKC turn valid UAX 31 identifiers into non-identifiers?

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_at_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
>
Received on Mon Jun 04 2018 - 22:44:16 CDT