Rename std.ctype to std.ascii?

[Jose Armando Garcia]

On Mon, Jun 13, 2011 at 10:28 PM, Jonathan M Davis <jmdavisProg at gmx.com> 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.