Lots of bool operations shouldn't compile

[Don Clugston]

Oskar Linde wrote:
> Don Clugston skrev:
>> Four examples, although it's only one bug. Almost all operations on 
>> bool should be disabled, but I found the ones below a little amusing. 
>> None of them should compile, but they all evaluate as "true".
>>
>> void main()
>> {
>>     if (true >= ireal.nan) { writefln("This is kind of ridiculous"); }
>>     if (false >= ireal.nan) { writefln("This is kind of ridiculous"); }
>>     if (true <> -2i) { writefln("NCEG operators too ??!!"); }
>>     if (false != -2i) { writefln("and again"); }
>> }
> 
> According to the specification, booleans are a numeric type. true == 1 
> and false == 0. So this error is not specific to bool.
> 
> Try s/true/1/g and s/false/0/g and you will get the same results.
> 
> The first two comparisons should be false I guess since they are 
> unordered. The other two are correct.

OK, there's another bug in there, comparing an int with an imaginary 
real should also not be legal.

     if (1 > -2i) { assert(0); }
     if (1 > ireal.nan) { assert(0); }

Reals and ireals cannot be compared. Ever.

> (If it is wise to have bool as a numeric type is a different question.)

I think it's very hard to justify numeric operations on bools.
(which is an _entirely_ different issue to implicit "!is null" in 
conditionals, I wholeheartedly support if (p), while(1){} and assert(0) ).
But I note that
bool b = 7;
is currently disallowed, while
b+=5;
compiles.
There's no reason to write b++, it's just letting bugs in. Write b=true 
instead. I hope that all such bug-breeding nonsense disappears. With a 
one bit integer, it wasn't clear how such things should behave (every 
other integral types wraps around, so b=5 should mean b=0 -- yuck!), but 
hopefully it can be cleared up now.