feat: `BaseClass|null` should be castable to `SubClass|null`

[trusktr]

This type cast is ok in TypeScript:

class Foo {}
class Bar extends Foo {
  n: i32 = 345
}

let a: Foo | null = null
let b = a as Bar | null

TS playground (no error)

AS playground (runtime error)

The error is:

Uncaught (in promise) RuntimeError: memory access out of bounds

Though depending on the program the stack trace can be different so I didn't include that part. Only the error message is the same.

---

Workaround for the time being:

class Foo {}
class Bar extends Foo {
  n: i32 = 345
}

let a: Foo | null = null
let b: Bar | null = a == null ? null : a as Bar

AS playground (no error)

But is the workaround good? Is there a way to make the result actually Bar | null in memory shape (whatever that may be)?

It seems the workaround will carry the issue up the call stack to end users (f.e. in the case of return Bar | null), meaning end users of an API will also have to apply the workaround anywhere they receive and subsequently use such a value.

[ramonGonzEdu]

This seems very dangerous because Bar might have a property that Foo does not have. Going from a subclass to a superclass is fine as they are supposed to share all properties/methods, but you should not be able to cast to a subclass.

[ramonGonzEdu]

class Foo {}
class Bar extends Foo {
  n: number = 345
}

let a: Foo = new Foo
let b: Bar = a as Bar

console.log(b.n);

The above snippet returns undefined when compiled thru typescript which would be a memory error on AssemblyScript

[dcodeIO]

In AS there is a runtime check on dynamic upcasts that if the cast would be invalid produces an error right on the cast. I believe the bug above is that it doesn't work properly when a null is in play.

[trusktr]

In AS there is a runtime check on dynamic upcasts that if the cast would be invalid produces an error right on the cast

That unexpected upcast runtime error is useful, preventing the upcast from going down the wrong class branch at runtime. 👍

@ramonGonzEdu The above example is contrived, but in general there are APIs like the DOM's document.querySelector(selectorString) that have a return type of Element | null, and we would like to be able to use any found element that is a subclass of Element.

This is a more realistic example:

// I know that the result will be an HTMLParagraphElement (that extends from Element)
const audio = document.querySelector('.my-audio') as HTMLAudioElement | null

if (!audio) throw new Error('not found')

log(audio instanceof HTMLAudioElement) // true

audio.pause() // I can use the method that I expect to exist.

and the particular bug is that the cast from Element | null to HTMLAudioElement | null in that example doesn't work. If the audio element exists, we know it is an HTMLAudioElement, and if it doesn't exist at the moment we query then it is null. The app author may know that only an HTMLAudioElement will ever have the class name my-audio.

[dcodeIO]

Should be fixed in #2042 afaict, but feel free to re-open if there are remaining issues :)