Comment #0 by bearophile_hugs — 2013-08-04T11:00:25Z
With dmd 2.064alpha this terrible program compiles with no errors nor warnings, and it runs with no asserts:
void main() {
double x;
int y;
y += x;
assert(y == int.min);
y += 3.5;
assert(y == -2147483644);
}
What I'd like: that code to become a compile time error (a "cannot implicitly convert expression" error), because I think it's against the idea of strong typing. I prefer a language that doesn't silently drops floating point parts (like 0.5 here) and that catches me if I increment an integer variable by mistake by a floating point value.
(Probably I will not close down this bug report, so if someone (like Walter) is against it then he should close it down. Such person should also show one or more practical situations where allowing that code gives an advantage over generating a compile-time error. I leave the burden of showing the usefulness on the shoulders of the person willing to close this issue down.)
In a dynamically typed language as Python2.6 int+float or int+=float return a float, so this behavour is acceptable:
>>> x = float("nan")
>>> y = 0
>>> y += x
>>> y
nan
I am aware that in D the increment at line 4 is accepted, but this is just a matter of disabling the value range tests that are so good in D, this is a different situation from adding a double to an int:
void main() {
int x;
byte y;
y += x; // line 4, OK
byte z = x; // Error: cannot implicitly convert
}
Comment #1 by robert.schadek — 2024-12-13T18:10:06Z