On Monday, October 30, 2017 11:04:32 Steven Schveighoffer via Digitalmars-d wrote: > On 10/29/17 3:10 PM, Nemanja Boric wrote: > > We've already reported this as a bug (I actually got quite burned on it, > > trusting assert(float_value) to prevent NaN's escaping the function), > > but there were different opinions on this, so it never got anywhere: > > https://issues.dlang.org/show_bug.cgi?id=13489 > > Wow, interesting dialog there. > > I'm in the camp that nan should be evaluated as false. I don't think I > like the idea that !nan is also false, because this makes !!nan true! > > TBH, I don't think I ever considered doing if(floatingpointvalue) to be > a good idea in C or D. I generally stay away from float, and especially > comparing to 0 directly.
Yeah. Honestly, I stay away from if(x) in general if x isn't a bool. I might occasionally do it for a pointer, but it's not like floating point types are the only ones that act badly with cast(bool) (e.g. dynamic arrays). It all works just fine if you understand what each of the types do with cast(bool), but it's just clearer if you make the check it explicit. I avoid floating point types on general principle though - not just in if statements. I'll use them when I need them, but if I can reasonably do something with an integral type instead, I will, because I don't want to deal with the inaccuracies of FP math. The fact that NaN == NaN is false and yet cast(bool)NaN is true though is just attrocious though. We aren't source compatible with C like C++ is, and yet we're still bound by it in so many small, stupid ways - largely because of the risk of ported code going badly. - Jonathan M Davis
