The recent discussion about ctype not supporting unicode made me wonder: why is the module called std.ctype instead of std.c.ctype? Isn't it a simple port of the C Runtime Library header?

I find it strange to have a non-Unicode module in the "D-style" hierarchy. Maybe this should be changed?

Hauke

In article <c9tmi2$3me$1@digitaldaemon.com>, Hauke Duden says...
>
>The recent discussion about ctype not supporting unicode made me wonder: why is the module called std.ctype instead of std.c.ctype? Isn't it a simple port of the C Runtime Library header?
>
>I find it strange to have a non-Unicode module in the "D-style" hierarchy. Maybe this should be changed?
>
>Hauke

Hauke: I thought the same thing too at first glance, but these function all seem to passed in a "D's" dchar (unicode-32 type) parameter, also many of them return a dchar value once called. So even tho the function names themselves may look like the "C" ones, I don't think they're really being pulled in from a "C" static library in any way. (But I could be wrong.)

David L. Davis wrote:

> In article <c9tmi2$3me$1@digitaldaemon.com>, Hauke Duden says...
> 
>>The recent discussion about ctype not supporting unicode made me wonder: why is the module called std.ctype instead of std.c.ctype? Isn't it a simple port of the C Runtime Library header?
>>
>>I find it strange to have a non-Unicode module in the "D-style" hierarchy. Maybe this should be changed?
>>
>>Hauke
> 
> 
> Hauke: I thought the same thing too at first glance, but these function all seem
> to passed in a "D's" dchar (unicode-32 type) parameter, also many of them return
> a dchar value once called. So even tho the function names themselves may look
> like the "C" ones, I don't think they're really being pulled in from a "C"
> static library in any way. (But I could be wrong.) 

The dchars are only an interface issue. Internally the functions don't support Unicode but work exactly like the C ones.

Hauke