Acknowledged
3 days ago
CIQQA-3581

Casting Float to Number does not yield Number

This code:

var myFloat = 5.0;
var myNumber = myFloat as Number;
var mod = myNumber % 1;

Compiles without warnings, but crashes at runtime with:

Error: Unhandled Exception
Exception: UnexpectedTypeException: Expected Number/Long, given Number/Float

As far as I can tell:

  • this behavior is undocumented
  • the types "Number/Long" and "Number/Float" are undocumented
  • the effects of casting numeric types are undocumented

Consequently I'm not sure how to characterize this bug. If it's expected, this is a documentation bug. If it's not expected, this is a runtime and/or compiler bug.

I read the relevant section on "type casting" in the SDK docs. I've reproduced the totality of the documentation on type casting here:

The as keyword can also be used in an expression to type cast a value to another type. This can be useful if the type is not clear to the type system.

This, unfortunately, does not help very much.

---

Tested on Descent G1 & G2 simulators

SDK 8.3.0

qlyoung
Parents
  • 2 days ago

    > Separately, I have also noticed that the compiler is unable to verify initialization if the assignment happens anywhere other than in "initialize()":

    Personally I am ok with this. After all how can the compiler ensure that a derived class does not override setThing so that thing is no longer initialized?

    Swift and TypeScript are no different.

    I think it's a lot more serious that in Monkey C, if a derived class's initializer does not explicitly call the parent/super class's initializer, that's only a compiler warning and not an error. (Note that super.initialize() will not automatically be called)

    That leads to potential situations like this, where the type checker fails to prevent a run time error (not for the first time) because the dev ignored a warning:

Comment
  • 2 days ago

    > Separately, I have also noticed that the compiler is unable to verify initialization if the assignment happens anywhere other than in "initialize()":

    Personally I am ok with this. After all how can the compiler ensure that a derived class does not override setThing so that thing is no longer initialized?

    Swift and TypeScript are no different.

    I think it's a lot more serious that in Monkey C, if a derived class's initializer does not explicitly call the parent/super class's initializer, that's only a compiler warning and not an error. (Note that super.initialize() will not automatically be called)

    That leads to potential situations like this, where the type checker fails to prevent a run time error (not for the first time) because the dev ignored a warning:

Children
No Data