"Jonathan M Davis" <[email protected]> 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
