I was working on some sort of math library for use in graphical computing and I wrote something like this:

const float PiOver2 = (atan(1.0) * 4) / 2;

Interestingly enough, I realized that atan() returns double (in this case) but wait, it's assigned to a float variable! Compiler didn't even emit warnings, let alone errors.

I see no reason as to why would this be legal in this century, especially in D.
So can someone tell me what's the argument against this?
Why type conversions differ between integral and floating types?
Why can't I assign a long to an int but it's fine when assigning double to float?

I think this is a serious topic and needs clarification.

On Saturday, 21 October 2017 at 20:17:12 UTC, NX wrote:
> I was working on some sort of math library for use in graphical computing and I wrote something like this:
>
> const float PiOver2 = (atan(1.0) * 4) / 2;
>
> Interestingly enough, I realized that atan() returns double (in this case) but wait, it's assigned to a float variable! Compiler didn't even emit warnings, let alone errors.
>
> I see no reason as to why would this be legal in this century, especially in D.
> So can someone tell me what's the argument against this?
> Why type conversions differ between integral and floating types?
> Why can't I assign a long to an int but it's fine when assigning double to float?
>
> I think this is a serious topic and needs clarification.

D is compliant with C++ in this case (see http://en.cppreference.com/w/cpp/language/implicit_conversion) so the question is rather why does C++ allow this conversion. When you convert a double to a float you're more likely to have a precision loss while when you convert an ulong to an int you risk a most serious data loss.

On Saturday, 21 October 2017 at 20:17:12 UTC, NX wrote:
> Interestingly enough, I realized that atan() returns double (in this case) but wait, it's assigned to a float variable! Compiler didn't even emit warnings, let alone errors.
>

There a few lessons here.

(1) D is not Java ;-)
(2) Know what types are being returned from your calls, before you call them.
(3) Know what the language spec says about conversions (and their order):
    - https://dlang.org/spec/type.html
(4) If unsure, test it:
    - https://dlang.org/phobos/std_traits.html#isImplicitlyConvertible

Only then should you start coding ;-)

oh...and...

(5) Don't waste time arguing with the spec ;-)
(6) Don't expect the compiler to not comply with the spec

On Sunday, 22 October 2017 at 02:25:44 UTC, codephantom wrote:
> On Saturday, 21 October 2017 at 20:17:12 UTC, NX wrote:
>> Interestingly enough, I realized that atan() returns double (in this case) but wait, it's assigned to a float variable! Compiler didn't even emit warnings, let alone errors.
>>
>
> There a few lessons here.
>
> (1) D is not Java ;-)

D is not C/C++ either. I fail to see how does it help to be C++ compliant. It's absolutely trivial to tell the compiler that conversion is on purpose by explicitly casting and it immensely helps to reduce bugs (since we are humans after all).

> (2) Know what types are being returned from your calls, before you call them.
> (3) Know what the language spec says about conversions (and their order):
>     - https://dlang.org/spec/type.html
> (4) If unsure, test it:
>     - https://dlang.org/phobos/std_traits.html#isImplicitlyConvertible
>
> Only then should you start coding ;-)

It never crossed my mind that D would allow such type conversion since I don't recall any language that markets itself as _modern_ allows it.

> oh...and...
>
> (5) Don't waste time arguing with the spec ;-)
> (6) Don't expect the compiler to not comply with the spec

I just think spec should be reviewed at this point.

On Sunday, 22 October 2017 at 10:57:24 UTC, NX wrote:
> D is not C/C++ either. I fail to see how does it help to be C++ compliant. It's absolutely trivial to tell the compiler that conversion is on purpose by explicitly casting and it immensely helps to reduce bugs (since we are humans after all).

Right, which is why C++ compilers will warn you about conversions that can be lossy. A lot of stuff that is valid C++ will be detected and complained about in typical production setups.

The D community thinks that all warnings should be errors, so I really don't think the argument that C++ allows something is a good one.

On Sunday, 22 October 2017 at 10:57:24 UTC, NX wrote:
> On Sunday, 22 October 2017 at 02:25:44 UTC, codephantom wrote:
>> On Saturday, 21 October 2017 at 20:17:12 UTC, NX wrote:
>>> Interestingly enough, I realized that atan() returns double (in this case) but wait, it's assigned to a float variable! Compiler didn't even emit warnings, let alone errors.
>>>
>>
>> There a few lessons here.
>>
>> (1) D is not Java ;-)
>
> D is not C/C++ either. I fail to see how does it help to be C++ compliant. It's absolutely trivial to tell the compiler that conversion is on purpose by explicitly casting and it immensely helps to reduce bugs (since we are humans after all).
>
>> (2) Know what types are being returned from your calls, before you call them.
>> (3) Know what the language spec says about conversions (and their order):
>>     - https://dlang.org/spec/type.html
>> (4) If unsure, test it:
>>     - https://dlang.org/phobos/std_traits.html#isImplicitlyConvertible
>>
>> Only then should you start coding ;-)
>
> It never crossed my mind that D would allow such type conversion since I don't recall any language that markets itself as _modern_ allows it.
>
>> oh...and...
>>
>> (5) Don't waste time arguing with the spec ;-)
>> (6) Don't expect the compiler to not comply with the spec
>
> I just think spec should be reviewed at this point.

Fortunately D provides enough to simplify self-discipline:

---
import std.traits;

struct FP(T)
if (isFloatingPoint!T)
{
    T _value;
    alias _value this;

    void antiCoercion(V)()
    {
        static assert(V.sizeof <= T.sizeof, "C++ float coercion is not allowed");
    }

    this(V)(V v) {antiCoercion!V; _value = v;}
    void opAssign(V)(V v) {antiCoercion!V; _value = v;}
}

void main()
{
    import std.math;
    FP!single PiOver2 = (atan(1.0) * 4) / 2;
}
---

On Sunday, 22 October 2017 at 12:17:49 UTC, Basile B. wrote:
> On Sunday, 22 October 2017 at 10:57:24 UTC, NX wrote:
>> [...]
>
> Fortunately D provides enough to simplify self-discipline:
>
> ---
> import std.traits;
>
> struct FP(T)
> if (isFloatingPoint!T)
> {
>     T _value;
>     alias _value this;
>
>     void antiCoercion(V)()
>     {
>         static assert(V.sizeof <= T.sizeof, "C++ float coercion is not allowed");
>     }
>
>     this(V)(V v) {antiCoercion!V; _value = v;}
>     void opAssign(V)(V v) {antiCoercion!V; _value = v;}
> }
>
> void main()
> {
>     import std.math;
>     FP!single PiOver2 = (atan(1.0) * 4) / 2;
> }
> ---

Oh, I meant to write "FP!float PiOver2 = (atan(1.0) * 4) / 2;"

Is there a list of such quirks or gotchas in dlang?

The ones I know of are

1. Implicit conversion from double to float

2. Integer division results in integer result truncation the fractional part.

3. ??

On Sunday, 22 October 2017 at 13:41:23 UTC, User wrote:
> Is there a list of such quirks or gotchas in dlang?
>
> The ones I know of are
>
> 1. Implicit conversion from double to float
>
> 2. Integer division results in integer result truncation the fractional part.
>
> 3. ??

#2 is common for statically typed languages.

I find implicit conversions to be the most common gotchas I've experienced, probably a few other things, but I can't recall.

On 10/22/17 9:41 AM, User wrote:
> Is there a list of such quirks or gotchas in dlang?
> 
> The ones I know of are
> 
> 1. Implicit conversion from double to float
> 
> 2. Integer division results in integer result truncation the fractional part.

These are not gotchas, as TDPL explains. One unpleasant related gotcha is implicit conversions across signedness and comparison of integral types with different signedness. -- Andrei