Float truthiness doesn't make sense

[rikkimax]

Truthiness for floats doesn't make a whole lot of sense:

void main()
{
     int a;
     assert(!a); // ok
     float b;
     assert(!b); // fails
}

Source: https://forum.dlang.org/post/vlvgvmedfprqubznvwww@forum.dlang.org

Between NaN, -0, infinity and all the other cases, it really doesn't align with the subject at all.

Good candidate for removal in an edition.

[Geod24]

There's an issue out there describing that. Sociomantic had a assert(someFloat) which passed when someFloat was NaN. We sent a bid worth a few trillion dollars to Google - thankfully we didn't pay that much. I still think NaN being falsy would make the most sense.

[adamdruppe]

nan being false makes sense to me. -0 meh not too concerned about that.

[crazymonkyyy]

"lets remove features to maintain a extremely unpopular feature"

[ntrel]

extremely unpopular

Possible selection bias there.

[crazymonkyyy]

correct, people still willing to talk to walter about airplane surgery after years and years of hell threads are more likely to agree with him

[Herringway]

extremely unpopular

Possible selection bias there.

100% of the sampled population (1 person) say it's bad.

[zero-vector]

100% of the sampled population (1 person) say it's bad.

You can count me in.

[CaradasProudfoot]

The problem is more subtle and is related to how the Unary NOT is either lowered or codegened.

void main()
{
    double d, e;
    assert(d != e);     // 1. OK NaN not eq to NaN
    assert(d != 0);     // 2. OK
    assert(!(d == 0));  // 3. OK
    assert(!d);         // 4. NG, should be same as 3. (or even 2)
} 

See the difference in the IR generated with LDC. For case 3 (that is after the assertPassed1 label in the IR) there is "ordered equal" while for case 4 (that is after the assertPassed3 label in the IR), it's an unordered equal ( see also the opcode ref for a complete description of NaN handling).

NB; dmd and ldc2 are consistent, that's why I use its IR, which highlight the problem better.

[CaradasProudfoot]

related:

• https://bugzilla-archive.dlang.org/bugs/13489/
• Fix issue 13489: Boolean semantics of floating point types should handle float #10363