Jonathan M Davis:

Goodness no.

:-)


1. Operating on a char is almost always the wrong thing to do.

A single char is often not so useful but I have to keep many mutable chars, keeping them as char[] instead of dchar[] saves both memory and reduces cache misses. The same is true for types like short or float, single ones are not so useful, but they sometimes become useful when you have many of them in arrays.

If I have to modify such char[], using toUpper() requires me a cast. And in my opinion it's not a good idea to return a dchar if you know the both the input and output of the function are a char.


If you really want to do that, then cast.

On the other hand casts in D have a certain risk, so reducing their number as much as possible is a good idea.


It should _not_ be encouraged.

This is silly, see the above explanation.


2. It would be disastrous if std.ascii's funtions didn't work on unicode. Right now, you can use them with ranges on strings which are unicode, which can be very useful. [...] but regardless, std.ascii is designed such that its functions will all operate on unicode strings. It just doesn't alter unicode characters and returns false for them with any of the query functions.

I see, and I didn't know this, I have misunderstood. I have thought of std.ascii functions as functions meant to work on just ASCII characters/text. But they are better defined as Unicode-passing functions. And yeah, it's written at the top of the module:

Functions which operate on ASCII characters. All of the functions in std.ascii accept unicode characters but effectively ignore them. All isX functions return false for unicode characters, and all toX functions do nothing to unicode characters.<

So now I'd like a new set of functions designed for ASCII text, with contracts to refuse not-ASCII things ;-)

Thank you for the answers Jonathan.

Bye,
bearophile

Reply via email to