frog should strip out calls to toDouble

[DartBot]

This issue was originally filed by [email protected]

---

In a program like this:

  int x = 23;
  double n = x.toDouble();

frog inserts an actual call to a function called toDouble (which is a no-op) in the generated code. It seems like this should get stripped out. (Or, another solution would be to not require the programmer to put it there in the first place, but I think that would be a language change.)

I'm not sure whether to regard this as a language issue or a frog issue, but somehow I think we need to this assignment without involving a real function call in the generated js.

[rakudrama]

You can only do what you suggest if you prove:
(1) x is not null on the second line
(2) the representation of the value of x is already double.

I consider (1) to be part language issue. Having nullable and non-nullable types would help with the 'proof'.

(2) depends a lot on whether we can continue to use JS numbers for all values of type int.

The generated code is quite odious since it causes the boxing of the JS number, only to forcefully unbox it. Both the boxing and unboxing (via this + 0) cause V8 to generate slow-path code. That could be ameliorated by generating a special dispatch.

[floitschG]

V8 doesn't need to box the number if "use strict" is used.
I opened a bug for that: Issue #781.

[DartBot]

This comment was originally written by [email protected]

---

Added Triaged label.

[DartBot]

This comment was originally written by [email protected]

---

I think the null handling is probably a separate issue. (In this example it would be fine if 'n' is assigned null if 'x' was null.)
The situation is I think the common case where you want to assign an int to a variable of type double. Currently we require the programmer to explicitly write the toDouble() call. This is OK (perhaps verbose, but arguably it has the advantage that the programmer sees that a conversion is involved that might lose precision). What I think is a problem is that the generated js is more roundabout than the equivalent hand-written javascript that would simply say: n = x.

[jmesserly]

as Stephen said, we need to call a method so we get a null check, or else insert the null check some other way.

[jmesserly]

Also, I think there's a readability argument to be made for keeping the JS code similar to the Dart code. Unless this is motivated by performance, I don't see the argument for changing it, other than switching to "use strict" as Florian suggested.

---

Removed Priority-Medium label.
Added Priority-Low, WontFix labels.