Ability to construct const/non-mutable arrays of unknown size from mutable arrays

[mkustermann]

It seems WasmGC currently can only create WasmGC arrays via the following instructions:

• array.new
• array.new_default
• array.new_fixed
• array.new_elem
• array.new_data

If the array's field type is const then after creation the array can only be accessed in read-only mode (accessing length & elements).

It can be very beneficial for compilers & optimizers to know that an array is const, so two loads at same index will always yield the same value, etc. So we'd like to take advantage of that. If we know the length of the array it's very convenient to use array.new_fixed. Though if we don't know the length and have the array values in a mutable array (i.e. field type is var) it seems the only way to create a const array from that would be to load elements from the mutable array, store into element section and then use array.new_elem. This seems super cumbersome.

Is there any simple way to create a const array with contents from a var array where the length is unknown?

It would be nice to have an array.copy() (related https://github.com/WebAssembly/gc/issues/313) or array.new_copy() (related: https://github.com/WebAssembly/gc/issues/367) that atomically create a const array and initializes it from a source array (const or var) - or a sub-range of one.

/cc @jakobkummerow @tlively @rossberg

[mkustermann]

Another issue regarding const/non-mutable arrays is that array.new_fixed is limited to 10k arguments. So it's rather hard to create const/non-mutable arrays that are larger than that (for mutable arrays that's easy to do via allocation + following store instructions)

[rossberg]

You are correct that the only way to create a useful immutable array is with array.new_fixed at the moment. The array.copy instruction you mention has been added to the proposal, but since it mutates its target, it isn't usable for immutable array. Something like array.new_copy would be a useful Post-MVP addition, as mentioned in #367.

For many or most use cases, it would be more flexible and useful to introduce readonly arrays (and generally fields), as mentioned in the Post-MVP document. That would also provide a way to initialise cyclic data structures, for which creating individual immutable arrays is not sufficient.

There also is a proposal for freezing values, though that's a more ambitious addition.