Type array access on Array<T> as Null<T>

[RealyUniqueName]

Current behavior

var a = ['hello'];
$type(a[1000]); // String
trace(a[1000]); //null

Behavior of this PR:

var a = ['hello'];
$type(a[1000]); // Null<String>
trace(a[1000]); //null

This PR adds Null<> for array read access on all platforms except Int, Bool, Float on static targets.
In addition to proper typing it also makes possible to check array access for null safety (i'm making a plugin for that).

[nadako]

I think it's for @ncannasse to review.

[ncannasse]

We don't make any difference between Null<String> and String and that can cause many issue with abstracts or other platform specific not nullable basic types (Single, hl.UI16 etc.) so I don't think this should be merged.

[RealyUniqueName]

We don't make any difference between Null and String

While there is no difference for Haxe type system, macros/plugins may want to deal with Null<>. And it's just semantically correct, because of Array spec.

that can cause many issue with abstracts

What kind of issues?

or other platform specific not nullable basic types (Single, hl.UI16 etc.)

What if we add @:notNullable meta to such types?

[RealyUniqueName]

or other platform specific not nullable basic types (Single, hl.UI16 etc.)

They already have @:notNull meta. I added a commit which handles it.

[ncannasse]

@RealyUniqueName you need to follow the types, since a TMono/TLazy might link to a basic type

[RealyUniqueName]

@ncannasse Types are already followed before checking for @:notNull: https://github.com/HaxeFoundation/haxe/pull/6825/files#diff-a5d39c7b15f0eb43335c0e74725dc438R2598

[RealyUniqueName]

Can i merge this?

[ncannasse]

Looks ok, but the readByte() commit has nothing to do with the fix, I think ?

[RealyUniqueName]

It has. Compiler complains on signtature difference with the parent method. Because this one is infered as Null<Int> while the parent one is Int