std.string will get the boot

[Andrei Alexandrescu]

bearophile wrote:
> Andrei Alexandrescu:
>> Currently arrays of characters count as random-access ranges, which is 
>> not true for arrays of char and wchar. I plan to make std.range aware of 
>> that and only characterize char[] and wchar[] (and their qualified 
>> versions) as bidirectional ranges.
> 
> 32 bits are not enough to represent certain "characters", they need more than one of such dchar. So dchar too may be a bidirectional range.

[citation needed]

> I can't remember the bit size of wchar and dchar. So names like char, char16 and char32 can be better...

I think it's a tad late for that.

> Sometimes I have ugly 7-bit ASCII strings, I am not sure I want to be forced to use cast(ubyte[]) every time I use an algorithm on them :-)

That's exactly one of the cases in which my change would help. char is 
UTF-8, so that's out as an option for expressing ASCII characters. 
You'll be able to define your own type:

struct AsciiChar {
    ubyte datum;
    ...
}

Then express stuff in terms of AsciiChar[] etc.

>> One problem I foresee is the growth of std.algorithm. It already has 
>> many things in it, and I fear that some user who just wants to trim a 
>> string may find it intimidating to browse through all that 
>> documentation.
> 
> It's not just a matter of documentation: to choose among n items a human needs more time as n grows (people that designg important menus in GUIs must be aware of this). So huge APIs slow down programming.
> A possible solution is to keep the std.string module, but make it just a list of aliases and thin wrappers around functions of std.algorithm, tuned for string processing (example I usually don't need tolower on generic arrays), there are some operations that are mostly useful for strings).

That's a good possibility.

Andrei