[Issue 13489] Boolean semantics of floating point types should use "<> 0"

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=13489

--- Comment #11 from Don <clugdbug at yahoo.com.au> ---
>> > (PS. Amounts like 80,833,756,980 Vietnamese Đồng do happen so limiting them
>> > is far from trivial...)
>> 
>> Yeah, you should have to check the currency and maintain a table of
>> conversion rates. Not a very promising approach ;-)

>That's 80 billion, far short of the 9 trillion in the original error. It is >essential to have sanity checks on the results of critical calculations.

FWIW we advertise some real estate in the €20 million price range. That is 0.4
trillion Đồng. I don't see any reason why the Đồng couldn't collapse even
further, and push it into the trillions. We have a long history of our sanity
checks being incorrect - the real world is a crazy place!
----

But, back on topic -- I think it is debatable whether assert(NaN) should be
false (as originally proposed here), or if it should fail to compile.

But I am certain that the current behaviour, that assert(NaN) passes, is wrong.

Pretty much all existing code containg
   assert(f);
except where f is known at compile time, is broken code. And this is the point
-- it's a place in the language where something that looks completely innocent,
is actually a landmine.


We can either make it have the behaviour that the author clearly intended, 
(ie, assert( !(f == 0) );  <--- Look Mum, no NCEG operators! )
or we could statically disallow implicit conversion from float to bool unless
we can prove that the float isn't NaN.

I mean, is NaN true, or is it false? The answer is NO, it isn't!

So a sensible mapping from IEEE float to bool is not possible.

--