1 matches bool, 2 matches long

Walter Bright newshound2 at digitalmars.com
Sun Apr 28 01:57:29 PDT 2013


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.



More information about the Digitalmars-d mailing list