std.algorithm.remove and principle of least astonishment

[Daniel Gibson]

Jonathan M Davis schrieb:
> On Tuesday, November 23, 2010 09:05:05 Andrei Alexandrescu wrote:
>>> You just don't seem to get that learning is location depended. What makes
>>> sense to YOU based on your location on the learning curve isn't absolute
>>> and does NOT reflect on people with a different location on the learning
>>> curve. This goes with many of your excellent implementations that get
>>> awful names. Very C++ on your part - you need to be a c++ guru just to
>>> write a hello world app.
>> I think I don't understand what you're suggesting.
> 
> I think that what he's saying is that the names char, wchar, and dchar as UTF-8, 
> UTF-16, and UTF-32 code points respectively make sense to you because you're 
> used to them, but for anyone learning D (particularly those who are used to char 
> in other languages being an ASCII character) don't find it at all intuitive or 
> obvious.
> 

And in Java a char is a 16bit unicode char that is generally handled as a code 
unit (since Java 1.5 32bit surrogate pair code units consisting of 2 chars are 
also supported, but I don't know if that really works in the whole standard lib 
and if people actually use it).
So also for Java programmers 1 char == 1 printed character, even though it 
supports more than ASCII.

> Honestly, the only semi-reasonable alternative to char, wchar, and dchar that I 
> can think of would be utf8, utf16, and utf32. 

Naa, that sounds like it's a whole UTF-* string and not just a code point to me.
utf8codepoint maybe? or utf8cp? ..
That sucks, IMHO it should stay the way it is.
But maybe an ASCII type (or maybe a more general 8bit text type that also 
supports ISO-* charsets etc?) would be helpful.
One that string literals can implicitly be converted to (so ubyte[] or an alias 
of that won't work). Also the compiler would have to make sure that all 
characters of the string can be represented in ASCII (or ISO-*).


Cheers,
- Daniel