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

[via Digitalmars-d-bugs]

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

Stewart Gordon <smjg at iname.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |smjg at iname.com

--- Comment #14 from Stewart Gordon <smjg at iname.com> ---
(In reply to David Eckardt from comment #0)
> ulong calcAmount ( double x )
> in
> {
>     assert(x); // succeeds for NaN
> }
> body
> {
>     // do calculation with x
>     return lround(fabs(x)); // returns 9223372036854775808 if x is NaN
> }
> ---

This looks to me like a problem with either lround or fabs, rather than with
the boolean semantics of a floating point.  Still, I agree that the boolean
semantics are an issue.

(In reply to Walter Bright from comment #2)
> In other words, both of them treat NaN as "TRUE". I fear that if we deviate
> from this behavior, we'll get subtly broken code that is written by former
> C++ programmers or that is transliterated from C++.

Can you give an example of how real-world code might explicitly rely on NaN
being boolean true?

(In reply to bearophile_hugs from comment #4)
> The current D situation seems standard:
> 
> http://stackoverflow.com/questions/9158567/nan-to-bool-conversion-true-or-
> false
> 
> http://stackoverflow.com/questions/15686318/why-do-not-a-number-values-equal-
> true-when-cast-as-boolean-in-python-numpy

The spec snippets pasted there don't mention NaN; as such, it looks to me like
an oversight.  Furthermore, I have just offered this insight on the C/C++
treatment:

But does NaN constitute a value at all? It's similar to NULL in typical
database systems. I was explicitly taught that NULL is not a value, but the
absence of a value. Unless there's evidence to the contrary, I think we can
claim the same about NaN. As such, I argue that this leaves the behaviour of
convert NaN to a bool undefined, unless there's something elsewhere in the spec
that covers the issue.

--