[phobos] std.ctype vs std.string

[Jesse Phillips]

Personally I have never used std.ctype and would never guess what is
actually in there. I thought it would be more like core.stdc.types (or
whatever it is called).

On Sun, May 22, 2011 at 10:25 PM, Jonathan M Davis <jmdavisProg at gmx.com> wrote:
> std.ctype and std.string overlap. std.ctype defines functions for determining
> the type of a character which are in standard C - including the non-camelcased
> names and return int instead of bool. std.string contains all the string stuff
> (which std.ctype doesn't have) as well as some character-specific stuff. It
> has hexdigits, digits, etc. which give the characters which return true (or
> non-zero at the moment) for the various functions in std.ctype, and it defines
> some functions similar to those in std.ctype. In fact, std.string defines
> iswhite and std.ctype defines isspace - both of which do the same thing with
> different implementations. So, I really think that their common functionality
> needs to be refactored.
>
> Would anyone be opposed to my moving the pieces of std.string which are
> similar to std.ctype's functionality (hexdigits, letters, whitespace, iswhite,
> etc.) into std.ctype and fixing the std.ctype functions so that they're names
> are properly camelcased and return bool (obviously, I'd leave in the old stuff
> as scheduled for deprecation)?