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

Reply via email to