Potentially eliminating Array.create<T>

[dcodeIO]

So I've been thinking about the new Array<T>(10) problematic a bit, and I figured that it might be worth to not throw on creating a holey array, but to instead throw when accessing a holey value. For instance, currently

class Foo {}
var arr = new Array<Foo>(10); // throws

but this could be modified to

class Foo {}
var arr = new Array<Foo>(10);
arr[0]; // throws

making

class Foo {}
var arr = new Array<Foo>(10);
for (let i = 0; i < 10; ++i) arr[i] = new Foo();
arr[0]; // work

at the expense of an additional runtime check whether a value is null on element access, if the array's value type is non-nullable. Assuming that branch prediction will do fine there since actually reading a null is unlikely and only happens in error cases. Thoughts?

[bowenwang1996]

Maybe we can do some benchmark to see how much performance loss this new approach would bring, but I think from the usability perspective this is certainly worth considering.

[MaxGraey]

Great idea. But I guess ut should be the same "null-ownership" analysis as in #456

[dcodeIO]

Turns out that there were two length-checks in Array#__get in the reference case already, which remains the same after the change. This is because the previous code tried to allow accessing out of .length while still inside .dataLength, which I think was wrong anyway in that one could theoretically unburry a reference that was already released or even collected. As such it seems that, comparing to the previous faulty code, we are not paying a tax.

[dcodeIO]

This is merged now, with updated documentation here: https://docs.assemblyscript.org/standard-library/array#api