Updating D beyond Unicode 2.0

[Joakim]

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.