Project Elvis

[Jonathan M Davis]

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