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. I can't remember the bit size of wchar and dchar. So names like char, char16 and char32 can be better... 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 :-) > 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). Bye, bearophile
