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
