Rename std.ctype to std.ascii?

Jonathan M Davis jmdavisProg at gmx.com
Mon Jun 13 18:28:27 PDT 2011


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


More information about the Digitalmars-d mailing list