std.string will get the boot

[Andrei Alexandrescu]

I plan a few improvements to Phobos that will improve string handling.

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. Also, std.range will define s.front 
and s.back for strings to return the correctly decoded dchar. Naturally, 
s.popFront and s.popBack will yank an entire encoded character, which is 
what you want most of the time anyway. (You're still free to do s = s[1 
.. $] if that's what you need.)

These changes will have the great effect of enabling std.algorithm to 
work with strings correctly without any further impedance adaptation. 
(At some point I'd defined byDchar to wrap a string as a bidirectional 
range; it works, but of course it's much better without an intermediary.)

Following that change, I plan to eliminate std.string entirely and roll 
all of its functionality into std.algorithm. This is because I noticed 
that I'd like many string functions to be available for other data 
types, and also because people who want to define their own non-UTF 
encodings can benefit of the support that UTF already has.

(As an example, startsWith or endsWith are very useful not only with 
strings, but general data as well.)

A possible idea would be to move algorithms out of std.string and roll 
std.utf and std.encoding into std.string. That way std.string becomes 
something UTF-specific, which may be sensible.

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. I wonder how we could break std.algorithm into smaller 
units (which is an issue largely independent from generalizing the 
algorithms now found in std.string).

Any ideas are welcome.


Andrei