On Monday, 9 May 2016 at 09:10:19 UTC, Walter Bright wrote:
> Don Clugston pointed out in his DConf 2016 talk that:
>
>     float f = 1.30;
>     assert(f == 1.30);
>
> will always be false since 1.30 is not representable as a float. However,
>
>     float f = 1.30;
>     assert(f == cast(float)1.30);
>
> will be true.
>
> So, should the compiler emit a warning for the former case?

I'd assume in the first case that the float is being promoted to double for the comparison. Is there already a warning for loss of precision? We treat warnings as errors in our C++ code, so C4244 triggers all the time in MSVC with integer operations. I just tested that float initialisation in MSVC, initialising a float with a double triggers C4305.

So my preference is "Yes please".

https://msdn.microsoft.com/en-us/library/th7a07tz.aspx
https://msdn.microsoft.com/en-us/library/0as1ke3f.aspx

On Monday, 9 May 2016 at 11:26:55 UTC, Walter Bright wrote:
> On 5/9/2016 3:16 AM, Jens Mueller via Digitalmars-d wrote:
>> Warning for those comparisons should be fine. Shouldn't mix them anyway.
>
> Too onerous.

Surely not too onerous if we're only talking about == ? Mixing floating point types on either side of == seems like a pretty solidly bad idea.

On 5/9/2016 4:16 AM, ZombineDev wrote:
> just like emitting a warning for mismatched signed/unsigned comparison.

Not at all the same, such are not always false.

On 5/9/2016 4:38 AM, Nordlöw wrote:
> Would that include comparison of variables only aswell?
>
>     float f = 1.3;
>     double d = 1.3;
>     assert(f == d); // compiler warning

No.

On Monday, 9 May 2016 at 12:28:04 UTC, Walter Bright wrote:
> On 5/9/2016 4:38 AM, Nordlöw wrote:
>> Would that include comparison of variables only aswell?
>>
>>     float f = 1.3;
>>     double d = 1.3;
>>     assert(f == d); // compiler warning
>
> No.

Just get rid of the problem : remove == and != from floats.

On 5/9/2016 5:21 AM, Ethan Watson wrote:
> I'd assume in the first case that the float is being promoted to double for the
> comparison. Is there already a warning for loss of precision?

Promoting to double does not lose precision.

> We treat warnings
> as errors in our C++ code, so C4244 triggers all the time in MSVC with integer
> operations. I just tested that float initialisation in MSVC, initialising a
> float with a double triggers C4305.

That's going quite a bit further.

On Monday, 9 May 2016 at 12:30:13 UTC, Walter Bright wrote:
> Promoting to double does not lose precision.

Yes, badly worded on my part, I was getting at the original assignment from double to float.

On 5/9/16 7:26 AM, Walter Bright wrote:
>> I wonder what's the difference between 1.30f and cast(float)1.30.
>
> There isn't one.

I know this is a bit band-aid-ish, but if one is comparing literals to a float, why not treat the literal as the type being compared against? In other words, imply the 1.3f. This isn't integer-land where promotions do not change the outcome.

What I see here is that double(1.3) cannot be represented as a float. So right there, the compiler can tell you, no, this is never going to be true. Something stinks when you can write an always-false expression as an if conditional by accident.

-Steve

On Monday, 9 May 2016 at 12:24:05 UTC, John Colvin wrote:
> On Monday, 9 May 2016 at 11:26:55 UTC, Walter Bright wrote:
>> On 5/9/2016 3:16 AM, Jens Mueller via Digitalmars-d wrote:
>>> Warning for those comparisons should be fine. Shouldn't mix them anyway.
>>
>> Too onerous.
>
> Surely not too onerous if we're only talking about == ? Mixing floating point types on either side of == seems like a pretty solidly bad idea.

Why only == ? The example also applies to opCmp.

    float f = 1.30;
    assert(f >= 1.30);
    assert(f <= 1.30);

On Monday, 9 May 2016 at 12:28:04 UTC, Walter Bright wrote:
> On 5/9/2016 4:38 AM, Nordlöw wrote:
>> Would that include comparison of variables only aswell?
> No.

Why?