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?

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?

What is the actual reason for the mismatch?

Does f lose precision as a float, while the 1.30 literal is a more precise double/real? Comparing float and double might be worth a warning.

Does it encode the two literals differently? If so, why?

On Monday, 9 May 2016 at 09:10:19 UTC, Walter Bright wrote:
> So, should the compiler emit a warning for the former case?

I'm not for a compiler change. IMO a library called std.sanity_float with a equal and a notequal function would be better.

Walter Bright via Digitalmars-d 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?

Since

assert(f == 1.30f);

passes I find the root cause lies in the implicit type conversion from
float to double. Warning for those comparisons should be fine. Shouldn't
mix them anyway.
I wonder what's the difference between 1.30f and cast(float)1.30.

Jens

On Monday, 9 May 2016 at 10:16:54 UTC, Jens Mueller wrote:
> Walter Bright via Digitalmars-d 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?
>
> Since
>
> assert(f == 1.30f);
>
> passes I find the root cause lies in the implicit type conversion from
> float to double. Warning for those comparisons should be fine. Shouldn't
> mix them anyway.
> I wonder what's the difference between 1.30f and cast(float)1.30.
>
> Jens

+1

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?

Yes, I think it is a good idea, just like emitting a warning for mismatched signed/unsigned comparison.

On 5/9/2016 2:25 AM, qznc wrote:
> What is the actual reason for the mismatch?

floats cannot represent 1.30 exactly, and promoting it to a double gives a different result than 1.30 as a double.

On 5/9/2016 3:16 AM, Jens Mueller via Digitalmars-d wrote:
> passes I find the root cause lies in the implicit type conversion from
> float to double.

That isn't going to change.

> Warning for those comparisons should be fine. Shouldn't mix them anyway.

Too onerous.

> I wonder what's the difference between 1.30f and cast(float)1.30.

There isn't one.

On Monday, 9 May 2016 at 09:10:19 UTC, Walter Bright wrote:
> So, should the compiler emit a warning for the former case?

Yes, please. I would prefer, at least, a warning flag for that.

On Monday, 9 May 2016 at 09:10:19 UTC, Walter Bright wrote:
> So, should the compiler emit a warning for the former case?

Would that include comparison of variables only aswell?

    float f = 1.3;
    double d = 1.3;
    assert(f == d); // compiler warning