On Mon, Jun 13, 2011 at 10:28 PM, Jonathan M Davis <[email protected]> wrote: > 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 >
or deprecate std.ctype and create a new std.ascii.
