Rename std.ctype to std.ascii?

[Jonathan M Davis]

On 2011-06-13 18:43, Jose Armando Garcia wrote:
> 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.

Well, yes. That's what would be happening. All of the old functions would be 
in std.ctype and put on the deprecation path, while the new std.ascii would 
have the new, properly camelcased functions in it. But what that's effectively 
doing is renaming std.ctype to std.ascii. It's just that std.ctype will stick 
around with its old functions until it's gone through the full deprecation 
cycle.

- Jonathan M Davis