On Friday, 21 September 2018 at 20:25:54 UTC, Walter Bright wrote:
When I originally started with D, I thought non-ASCII
identifiers with Unicode was a good idea. I've since slowly
become less and less enthusiastic about it.
First off, D source text simply must (and does) fully support
Unicode in comments, characters, and string literals. That's
not an issue.
But identifiers? I haven't seen hardly any use of non-ascii
identifiers in C, C++, or D. In fact, I've seen zero use of it
outside of test cases. I don't see much point in expanding the
support of it. If people use such identifiers, the result would
most likely be annoyance rather than illumination when people
who don't know that language have to work on the code.
Extending it further will also cause problems for all the tools
that work with D object code, like debuggers, disassemblers,
linkers, filesystems, etc.
To wit, Windows linker error with Unicode symbol:
https://github.com/ldc-developers/ldc/pull/2850#issuecomment-422968161
Absent a much more compelling rationale for it, I'd say no.
I'm torn. I completely agree with Adam and others that people
should be able to use any language they want. But the Unicode
spec is such a tire fire that I'm leery of extending support for
it.
Someone linked this Swift chapter on Unicode handling in an
earlier forum thread, read the section on emoji in particular:
https://oleb.net/blog/2017/11/swift-4-strings/
I was laughing out loud when reading about composing "family"
emojis with zero-width joiners. If you told me that was a tech
parody, I'd have believed it.
I believe Swift just punts their Unicode support to ICU, like
most any other project these days. That's a horrible sign, that
you've created a spec so grotesquely complicated that most
everybody relies on a single project to not have to deal with it.
