Is this intended behavior? I can't seem to find it documented anywhere, I would think the loss in precision would atleast be a warning.

real x = 10;
float y = x; // No error or warning

real to double and double to float also work.

On Wednesday, 22 June 2016 at 05:04:42 UTC, Tofu Ninja wrote:
> Is this intended behavior? I can't seem to find it documented anywhere, I would think the loss in precision would atleast be a warning.
>
> real x = 10;
> float y = x; // No error or warning
>
> real to double and double to float also work.

Intended behaviour (in TDPL and all), and same behaviour than C.
I'm not sure of the reason.

On Wednesday, 22 June 2016 at 08:57:38 UTC, Guillaume Piolat wrote:
> On Wednesday, 22 June 2016 at 05:04:42 UTC, Tofu Ninja wrote:
>> Is this intended behavior? I can't seem to find it documented anywhere, I would think the loss in precision would atleast be a warning.
>>
>> real x = 10;
>> float y = x; // No error or warning
>>
>> real to double and double to float also work.
>
> Intended behaviour (in TDPL and all), and same behaviour than C.
> I'm not sure of the reason.

That's a little disconcerting, would be nice if there was a compiler flag to give a warning on the precision loss.

On Wednesday, June 22, 2016 05:04:42 Tofu Ninja via Digitalmars-d-learn wrote:
> Is this intended behavior? I can't seem to find it documented anywhere, I would think the loss in precision would atleast be a warning.
>
> real x = 10;
> float y = x; // No error or warning
>
> real to double and double to float also work.

Well, that particular value should probably work thanks to VRP (value range propagation), since 10 can fit into float with no loss of precision. However, what's far more disconcerting is that

real x = real.max;
float y = x;

compiles. real to float is a narrowing conversion, which should be an error barring the compiler detecting that the value will fit in the target type even if it's a narrowing conversion (which only happens with VRP). That's not the sort of thing that I would have expected to be broken such that it begs the question as to whether it's intentional, but given that narrowing conversions without a cast are illegal everywhere else, this definitely seems broken.

- Jonathan M Davis

On Wednesday, 22 June 2016 at 14:17:42 UTC, Jonathan M Davis wrote:
> Well, that particular value should probably work thanks to VRP (value range propagation), since 10 can fit into float with no loss of precision. However, what's far more disconcerting is that
>
> real x = real.max;
> float y = x;
>
> compiles. real to float is a narrowing conversion, which should be an error barring the compiler detecting that the value will fit in the target type even if it's a narrowing conversion (which only happens with VRP). That's not the sort of thing that I would have expected to be broken such that it begs the question as to whether it's intentional, but given that narrowing conversions without a cast are illegal everywhere else, this definitely seems broken.
>
> - Jonathan M Davis

Should I make a bug report? I am not sure it's a bug, seems intentional. Maybe a dip for a compiler flag to warn on implicit down conversions, but it would be a pretty small dip.

On Thursday, June 23, 2016 04:55:09 Tofu Ninja via Digitalmars-d-learn wrote:
> On Wednesday, 22 June 2016 at 14:17:42 UTC, Jonathan M Davis
>
> wrote:
> > Well, that particular value should probably work thanks to VRP (value range propagation), since 10 can fit into float with no loss of precision. However, what's far more disconcerting is that
> >
> > real x = real.max;
> > float y = x;
> >
> > compiles. real to float is a narrowing conversion, which should be an error barring the compiler detecting that the value will fit in the target type even if it's a narrowing conversion (which only happens with VRP). That's not the sort of thing that I would have expected to be broken such that it begs the question as to whether it's intentional, but given that narrowing conversions without a cast are illegal everywhere else, this definitely seems broken.
> >
> > - Jonathan M Davis
>
> Should I make a bug report? I am not sure it's a bug, seems intentional. Maybe a dip for a compiler flag to warn on implicit down conversions, but it would be a pretty small dip.

You're original code is almost certainly not a bug thanks to VRP, but I would think that the example with real.max would be. So, it makes sense to me to report it. Worst case, it gets closed as invalid. I certainly wouldn't suggest a DIP for it at this point. If the bug were closed as invalid, then then a DIP might make sense (though if it were intentional, then I question that we could get Walter to change it), but I'd treat it as a bug first.

- Jonathan M Davis

On 6/23/16 5:37 AM, Jonathan M Davis via Digitalmars-d-learn wrote:
> On Thursday, June 23, 2016 04:55:09 Tofu Ninja via Digitalmars-d-learn wrote:

>> Should I make a bug report? I am not sure it's a bug, seems
>> intentional. Maybe a dip for a compiler flag to warn on implicit
>> down conversions, but it would be a pretty small dip.

It's not a bug. Floating point is in general an approximation, so it's not expected to accurately capture the value. It's not the same as a narrowing conversion.

For instance:

int x = 1_000_000;
byte b = cast(byte)x;
assert(b == 64);

64 is nowhere near 1 million.

However:

double x = 1_000_000_000_000_000;
float f = x;
assert(f == 999_999_986_991_104);

Now, f and x aren't equal, but they are very close. Much more accurate than 64 and 1 million. Whenever you work with floating point, the loss of precision must be expected -- a finite type cannot represent an infinite precision number.

> You're original code is almost certainly not a bug thanks to VRP

No, VRP only works on the current expression (statement maybe?). The compiler does not examine previous lines to see what the range of a particular variable should be.

For example, this is an error:

int x = 10;
byte b = x; // error

This isn't:

int x;
byte b = x = 10;

-Steve

On Thursday, 23 June 2016 at 13:57:57 UTC, Steven Schveighoffer wrote:
> Whenever you work with floating point, the loss of precision must be expected -- a finite type cannot represent an infinite precision number.

The loss in precision should still be a warning. If I am using reals then I obviously needed a certain level of precision, I don't want to accidentally lose that precision somewhere because the compiler decided it was not important enough to warn me about it.

On 6/23/16 11:16 AM, Tofu Ninja wrote:
> On Thursday, 23 June 2016 at 13:57:57 UTC, Steven Schveighoffer wrote:
>> Whenever you work with floating point, the loss of precision must be
>> expected -- a finite type cannot represent an infinite precision number.
>
> The loss in precision should still be a warning. If I am using reals
> then I obviously needed a certain level of precision, I don't want to
> accidentally lose that precision somewhere because the compiler decided
> it was not important enough to warn me about it.

I disagree. I've used languages where converting floating point types is not implicit, and it's painful. Most of the time, the loss in precision isn't important.

-Steve

On Thursday, 23 June 2016 at 15:25:49 UTC, Steven Schveighoffer wrote:
> I disagree. I've used languages where converting floating point types is not implicit, and it's painful. Most of the time, the loss in precision isn't important.
>
> -Steve

Which is why a flag would be nice, for some applications the precision matters, for some it doesn't.