On Thursday, 20 September 2012 at 17:05:18 UTC, bearophile wrote:
monarch_dodra:
Would that actually change anything though? I mean what with
alignment and everything, wouldn't returning a char be just as
expansive? I'm not 100% sure.
If you are thinking about the number of operations, then it's
the same, as both a char and dchar value go in a register. The
run time is the same, especially after inlining.
What is your use case that would require this?
I have a char[] like:
['a','x','b','a','c','x','f']
Every char encodes something. Putting it to upper case means
that that data was already used:
['a','X','b','a','C','x','f']
In this case to use toUpper I have to use:
cast(char)toUpper(foo[1])
What's I am trying to minimize is the number of cast(). On the
other hand even in C toupper returns a type larger than char:
http://www.acm.uiuc.edu/webmonkeys/book/c_guide/2.2.html
It's just D has contract programming, and this module is
written for ASCII, so it's able to be smarter than C functions,
and return a char.
Bye,
bearophile
That's what I thought. You have a valid point (IMO) but at the
same time, using the ASCII methods on non-ascii characters is
also legit operation.
I guess we'd need the extra "std.strictascii" module (!) for
operations that would accept ASCII char, and return a ASCII char.
I'd support such an ER, I think it would. Allow users (such as
you) to have tighter constraints if needed, while still keeping
std.ascii for "safer" ASCII operations.
