On 6/23/16 11:41 AM, Tofu Ninja wrote:
> 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.
>>
>
> Which is why a flag would be nice, for some applications the precision
> matters, for some it doesn't.

You can attempt to make a wrapper that prevents the conversion, probably the best that can be had.

-Steve

On 06/23/2016 06:57 AM, Steven Schveighoffer wrote:
> 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);

But there is also the representable value range. The difference between the maximum values are worse in the case of floating point types.

void main() {
    pragma(msg, long.max / byte.max);
    pragma(msg, real.max / float.max);
}

72624976668147841L
3.49631e+4893L

So it's more nowhere near for floating point types from that point of view: :)

Ali

On Thursday, 23 June 2016 at 15:25:49 UTC, Steven Schveighoffer wrote:
> 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.

This is so wrong. _especially_ when you have parameter overloading/templates. It means that you accidentally can trash a computation by getting the wrong function. That is not type-safe in my book.

Jonathan's max-value example is a good one. The distinction between infinity and a large actual value is an important one.

On Friday, 24 June 2016 at 08:52:48 UTC, Ola Fosheim Grøstad wrote:
> This is so wrong. _especially_ when you have parameter overloading/templates. It means that you accidentally can trash a computation by getting the wrong function. That is not type-safe in my book.
>
> Jonathan's max-value example is a good one. The distinction between infinity and a large actual value is an important one.

I am glad I was not the only one who thought that sounded a little crazy... I thought D was supposed to be type safe. I think I will make a bug report and see where that goes.

On Friday, 24 June 2016 at 20:10:16 UTC, Tofu Ninja wrote:
> I am glad I was not the only one who thought that sounded a little crazy... I thought D was supposed to be type safe. I think I will make a bug report and see where that goes.

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

On Friday, 24 June 2016 at 20:10:16 UTC, Tofu Ninja wrote:
> I am glad I was not the only one who thought that sounded a little crazy... I thought D was supposed to be type safe. I think I will make a bug report and see where that goes.

It is one of those cases where it made sense in C because it puts the burden on the programmer and the C-convention is to have the type in the name so it is "somewhat explicit" in C. C++ compilers solve this by having warning-options for float->double and also double->float conversions.

The conversion becomes rather problematic if you use Infinity to mean an open-ended interval. It means that a closed interval can implicitly be converted into an open-ended interval... :-/