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 <[email protected]> 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)? _______________________________________________ phobos mailing list [email protected] http://lists.puremagic.com/mailman/listinfo/phobos
