The by-reference @ array accessor only makes sense in the context of writing to an array. It shouldn't be necessary in FrostyCat's script.
Indeed. In fact, on VM it will be slower than regular read, because []-read is assigned a bytecode instruction, while [@]-read is compiled to an array_get call (same as other accessors). array_get, in turn, used to have bugs (returning 0 if argument is not an array) for some time, and I recall someone mentioning that there isn't any real reason to use it under normal circumstances.
Accessor chaining is compiler-side, and I assume that it'll get looked into sooner than later - I was able to implement this for
GMLive without too much struggle, for example. The one nasty bit is GameMaker's create-on-write\copy-on-write behaviour, which means that
must be compiled to (pseudocode)
Code:
if (!is_array(arr)) arr = [];
if (!is_array(arr[0])) arr[0] = [];
arr[0][1] = 2;
but may not
duplicate expressions for risk of side effects, meaning that intermediate values may have to be stored somewhere when needed. While on VM this is a matter of smart use of `dup` instruction, on JS/YYC this requires unrolling expressions
Code:
arr[a()][b()] = 1;
// ->
if (!is_array(arr)) arr = [];
var ind1 = a();
var arr1 = arr[ind1];
if (!is_array(arr1)) { arr1 = []; arr[ind1] = arr1; }
arr[b()] = 1;
Things get weirder with post-increment/post-decrement;
There is also a thing where
would not be possible to correctly compile with create-on-write rules at all, since the original location for newly made array to be assigned to would be undetermined.