Rename std.ctype to std.ascii?

[Jouko Koski]

"Jonathan M Davis" <jmdavisProg at gmx.com> wrote:
> On 2011-06-14 11:53, Jouko Koski wrote:

>> I would not consider it being good idea to include this kind of 
>> ascii-only
>> utilities in the standard-ish library.

> For some classes of operations, it makes perfect sense to be checking for
> ASCII characters only. For others, it's just people not worrying about
> internationalization like they should be. For instance, format strings 
> don't
> care about unicode as far as their escape sequences go. %a, %d, etc. are 
> all
> pure ASCII.

Do we really need a common library utility for such a bounded domain? I 
would vote dropping ascii-only std.ctype altogether. Those who know and 
ensure that they are dealing with ascii-only, ebcdic-only or whatever-only 
representations can easily write their own utilities to their particular 
domains - maybe even better optimized than std.ctype because the domain may 
be even more restricted. A common use ascii-only utility will be used 
inevitably in places where it shouldn't.

> std.ctype/std.ascii deals with ASCII for those situations where you really 
> do
> only care about ASCII. It deals with unicode characters, but it returns 
> false
> for everything with them which returns a bool, and it never tries to 
> change
> their case. std.uni actually deals with unicode and worries about things 
> like
> whether a unicode character is uppercase or not.

That is what <ctype.h> (or <wctype.h>) utilities do when the default locale 
setting is in effect. Some other posters seem to suggest that a more 
generalized library module does this, too, without losing performance.

-- 
Jouko