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
