std.ctype is modeled after C's ctype.h. It has functions for operating on characters - particularly functions which indicate the type of a character (I believe that ctype stands for character type, so that makes sense). For instance, isdigit will tell you whether a particular character is a digit. It only works on ASCII characters (non-ASCII characters return false for functions like isdigit and functions like toupper do nothing to non-ASCII characters).
std.uni, on the other hand, operates on characters just like std.ctype does, but it extends its charter to unicode characters (e.g. it has isUniUpper which _does_ work on unicode characters, unlike std.ctype's isupper). The thing is that aside from those familiar with C/C++, most programmers are likely to find the module name ctype to be rather uniformative. If they're looking for something like isdigit, they're not terribly likely to go looking at std.ctype first. And I'm not sure that std.ascii will be all that much more obvious to them, but it fits in much better with std.uni. std.ascii gets the character functions which operate only on ASCII characters, and std.uni gets the character functions which operate on unicode characters in addition to ASCII characters. I don't think that the change of module name is enough of an improvement to merit changing the name just because ctype is arguably bad. However, as it turns out, _no_ function in std.ctype is properly camelcased, and many of them return int instead of bool (which the C functions they're modeled after do but which is not particularly D-like and can cause problems when you actual _need_ them to return bool). And it has been made very clear in past discussions in this newsgroup that the consensus is that we prefer that Phobos functions follow Phobos' naming conventions (which means camelcasing) rather than matching the casing of functions in other languages. So, all of the functions in std.ctype need to be renamed. I now have a pull request which creates properly camelcased versions of all of them ( https://github.com/D-Programming-Language/phobos/pull/101 ). The thing is though that because _every_ function in std.ctype is renamed, the cost of renaming the entire module (as far as people updating their code to use functions such as isDigit instead of isdigit goes) is essentially the same if as just renaming the functions in-place. In either case, the old functions will go through the full deprecation process before they're actually gone, so no one's code will suddenly break because of the changes, but any code that uses the old functions will eventually have to be change to use the properly named ones. And since the cost to making those changes is essentially the same whether we replace the whole std.ctype module or whether we replace all of its functions, I'm wondering whether it would be worthwhile to take this opportunity to rename std.ctype? I don't think that the name change is enough of an improvement to do it if it's going to break everyone's code, but given that fixing all of its functions gives us a perfect opportunity to rename it at no additional cost, I feel that the question should be posed. Should we rename std.ctype to std.ascii? Or should we just keep the old name, which is familiar to C programmers? - Jonathan M Davis