Updating D beyond Unicode 2.0

[Steven Schveighoffer]

On 9/26/18 2:50 AM, Shachar Shemesh wrote:
> On 25/09/18 15:35, Dukc wrote:
>> Another reason is that something may not have a good translation to 
>> English. If there is an enum type listing city names, it is IMO better 
>> to write them as normal, using Unicode. CityName.seinäjoki, not 
>> CityName.seinaejoki.
> 
> This sounded like a very compelling example, until I gave it a second 
> thought. I now fail to see how this example translates to a real-life 
> scenario.
> 
> City names (data, changes over time) as enums (compile time set) seem 
> like a horrible idea.
> 
> That may sound like a very technical objection to an otherwise valid 
> point, but it really think that's not the case. The properties that 
> cause city names to be poor candidates for enum values are the same as 
> those that make them Unicode candidates.

Hm... I could see actually some "clever" use of opDispatch being used to 
define cities or other such names.

In any case, I think the biggest pro for supporting Unicode symbol names 
is -- we already support Unicode symbol names. It doesn't make a whole 
lot of sense to only support some of them.

-Steve