std.string will get the boot

[Jacob Carlborg]

On 1/29/10 18:36, Andrei Alexandrescu wrote:
> 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.

I would keep std.string for string specific functions and perhaps 
publicly import std.algorithm. For exmaple functions like: tolower, icmp 
and toStringz.

> (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).

Perhaps it's time to start adding more packages than just the std. Make 
std.algorithm a package and try to split it into several modules.

> Any ideas are welcome.
>
>
> Andrei