https://issues.dlang.org/show_bug.cgi?id=13489
--- Comment #11 from Don <[email protected]> --- >> > (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. --
