On 4/27/2013 5:49 PM, Jonathan M Davis wrote:
Yes, but I honestly think that that's problem too. I think that there's more
of an argument for treating characters as integral types than bool, as they
really do hold an encoded number internally, but they really aren't treated as
integers in general, and I think that treating them as integers implicitly
tends to cause problems when conversions come into play.
Are you really solving a problem, or just creating new ones? I'd rather have a
small set of simple, easily explained rules and accept a few issues with them
than have a bewildering set of complicated rules trying to solve every problem.
True, it's nice to not have to cast '0' - 42 when assigning it back to a char,
but I also don't think that it's all that big a deal for the cast to be
required,
I've used languages enough that did require such casts. It left an enduring bad
taste.
and I think that allowing things like "foo" ~ 42 is just asking for
bugs, particularly when you can easily do something like \u0042 if you
actually want a numberic character literal. "foo" ~ true just so happens to be
an extreme case of this, as it clearly makes no sense, and if it happens with
variables rather than literals, it's not necessarily as obvious that it's
happening.
We need to be careful with how strongly stuff is typed, because we don't want
to require casts everywhere, as that can introduce other types of bugs because
casts are so blunt - which is why not requiring casting when converting
between int and uint is probably ultimately a good idea - but characters and
bool really aren't integral types, even if they do have a relation to them,
and I firmly believe that treating them as integral types implicitly causes
more bugs than it fixes.
And I just as firmly believe they really are integral types. After all, we
constantly manipulate them as integral types:
1. changing case
2. using them as array indices
3. doing utf encoding and decoding
4. generating hashes
5. sorting
6. encoding and decoding integer strings (printf/scanf)
7. compression/decompression
8. encryption/decryption
In fact, treating a char as a "character" actually seems to be in the minority
of uses!
Clearly, with how the language currently works, that should raise a red flag,
but I think that it's clear that the majority of us would have expected
foo(bool) to work with bools, and foo(long) to deal with integral values,
allowing you to just have two overloads rather than several.
I don't think it is fundamentally different from the char issue.
It is definitely a matter of perspective, but I also think that it's fairly
clear that most people here don't expect bool to be treated as an integral
type and don't like the fact that it is. If it's truly an integral type, why
have true and false in the first place? Why not just use 1 and 0?
As history has amply shown, people simply like the true & false literals, and if
we didn't supply them, they'd add them to their code in a multitude of
incompatible ways (this was a considerable nuisance in C).
It seems like
implicit casting is making it so that there's no real difference between them,
and C++ introduced a bool type rather than sticking with C's approach in order
to be able to distinguish between bools and integers when overloading. We
appear to be doing a poor job of that.
There is a place for a 1 bit integer type, and bool fills that role nicely. That
doesn't mean it isn't an integer, it's just a boundary case of integers.
