JavaScript doesn't have integers. I suspect that the Dart VM will support integers with overflow. So yes, I suspect in that case they are different.
I also strongly suspect this will not be a significant edge case in practice: if you use integer types in your dart code, then you clearly don't want doubles to result from a calculation. So the only unexpected "surprise" you would encounter there is if you expect integer overflow but get doubles. If you are writing code that expects integer overflow to happen a certain way, you're doing it wrong. If you're writing code that doesn't expect integer overflow, and you want integers, then you're going to be fucked either way. Either you end up with doubles and type errors or an overflow and your result is wrong.
Changing things as entrenched as JavaScript while maintaining backwards compatibility is messy and hard. Especially given some of the horrible characteristics of the language. I'm glad someone's at least trying.
> JavaScript doesn't have integers. I suspect that the Dart VM will support integers with overflow. So yes, I suspect in that case they are different. [..] I also strongly suspect this will not be a significant edge case in practice [..] If you are writing code that expects integer overflow to happen a certain way, you're doing it wrong.
It's a valid position to say that relying on integer overflow in one's Dart code is "wrong". But you will need to carefully educate coders about that, since relying on overflow is common in popular languages like C and C++. This won't be easy.
Another big worry is that this could lead to very hard to diagnose bugs. Having the native VM and the compiled code have different semantics in subtle ways is risky - unintended overflows will lead to different bugs in different cases.
Also, integer overflow is not the only case where this problem arises. It also happens with say division of an integer. Will Dart compiled code in JS add proper rounding correction to all divisions of integers? Or will this be another case where the VM differs from compiled code?
Overall, it seems much simpler and safer to just correct overflows in the compiled code.
> Especially given some of the horrible characteristics of the language [JavaScript]
It's fine if you don't like something of course, but I don't think calling languages "horrible" is going to lead to a productive discussion.
> But you will need to carefully educate coders about that, since relying on overflow is common in popular languages like C and C++.
This is something we're aware of and we know we need to be extra clear and loud about it.
> Also, integer overflow is not the only case where this problem arises.
As far as I know, bigints are the only place where the VM and the generated JS intentionally differ in behavior. We are trying very hard to keep the two in sync.
> It also happens with say division of an integer. Will Dart compiled code in JS add proper rounding correction to all divisions of integers?
Dart has two division operators (~/ and /) to handle this. The former rounds (truncates? I'm not sure) and the latter does floating point division. So it's always the operation that determines the type of the result, and not the type of the operands.
> Overall, it seems much simpler and safer to just correct overflows in the compiled code.
Simpler: yes. Safer: yes. Unfortunately, it's also much slower.
Rolling your own numeric type in JS means slower behavior when you have overflowed and slow behavior even when you haven't. If you're generating code for "a + b", you can't compile that to "a + b" in JS because you need to check for overflow and handle the fact that a or b could be bignums.
We really want the compiled JS to behave the same as native code, but if it's significantly slower, people just won't use it at all. It's an unfortunate trade-off.
> > Overall, it seems much simpler and safer to just correct overflows in the compiled code.
> Simpler: yes. Safer: yes. Unfortunately, it's also much slower.
In my experience with something similar - compiling LLVM to JavaScript in Emscripten, which also needs to properly implement integer math in JavaScript - it actually isn't a lot slower. On the Emscripten benchmark suite enabling overflow correction everywhere makes it only 5% slower. We might be running very different benchmarks I guess.
(However, overflow correction does increase code size a lot, which is why we have tools that let you get rid of it where it isn't needed.)
JavaScript doesn't have integers. I suspect that the Dart VM will support integers with overflow. So yes, I suspect in that case they are different.
I also strongly suspect this will not be a significant edge case in practice: if you use integer types in your dart code, then you clearly don't want doubles to result from a calculation. So the only unexpected "surprise" you would encounter there is if you expect integer overflow but get doubles. If you are writing code that expects integer overflow to happen a certain way, you're doing it wrong. If you're writing code that doesn't expect integer overflow, and you want integers, then you're going to be fucked either way. Either you end up with doubles and type errors or an overflow and your result is wrong.
Changing things as entrenched as JavaScript while maintaining backwards compatibility is messy and hard. Especially given some of the horrible characteristics of the language. I'm glad someone's at least trying.