cast mutable array to immutable array

[Yu-zh]

Hi,

The following code attempts to cast a mutable array to an immutable array, but traps at runtime:

(module
  (type $ma (array (mut i32)))
  (type $ima (array i32))
  (func (param $a (ref $ma)) (result (ref $ima))
    (local.get $a)
    (ref.cast (ref $ima))
  )
)

Use Case: I'm implementing strings as immutable arrays in my language. For operations like string append, I need to:

1. Allocate a mutable array
2. Write the characters
3. Convert it to an immutable array

Questions:

1. Is there a way to cast from mutable to immutable arrays?
2. If not, what's the recommended approach for implementing immutable string operations?

Thanks for your help!

[rossberg]

Such a cast is not allowed by the type system, and it would generally be unsound due to the possibility of aliasing: multiple references to the same array may exist, and if one still is of mutable type, then it could continue to mutate it, even though other references assume it's immutable.

The save alternatives would be the following, none of which are currently provided:

• A new read-only mode (different from immutable in that it does not assume that nobody else can mutate it). This is part of the possible Post-MVP feature set for Wasm GC.
• An allocation operator creating an immutable array from a mutable one by copying it.
• An extension to the type system with ownership and linearity tracking, as e.g. Rust uses. However, that is complex and unlikely to work well for Wasm.

However, in practice, there is no reason to have strings immutable inside a language runtime. Wasm is an abstraction of hardware, and normal hardware memory is always mutable. The only reason that immutable arrays exist in Wasm in the first place is that immutability sometimes allows more subtyping. But there is no subtyping on numeric types, so there is no benefit to using immutable arrays over numeric types. Such internal use of mutability should of course be encapsulated and not exposed to users of your language.

[Yu-zh]

Thanks for your explanation. I have a follow-up question:

However, in practice, there is no reason to have strings immutable inside a language runtime.

I am expecting immutable data enjoys more aggressive optimization when executed by the runtime. Isn't that a reasonable motivation?

[rossberg]

Wasm generally assumes that optimisations are already performed by the producer where possible. And in the case of first-class immutable arrays, there usually isn't much potential for dynamic optimisations that couldn't already be performed statically, so I don't expect most engines to do much with them.