Post-MVP feature requests

[tlively]

These are the feature requests that came up at the subgroup meeting on October 3, 2023:

1. Non-throwing variants of instructions or trap handlers
2. Constant array.new_elem and array.new_data
3. initialize-once globals
4. Feature detection for experimenting with new features
5. Type imports
6. Controlling meta-objects/RTTs/headers
7. Static fields
8. Weak references
9. Finalization
10. Eliminate method receiver casts
11. Ergonomic JS/WasmGC interop
12. Arbitrary multi-byte loads and stores to byte arrays (Multibyte access to (array i8) #395

[rossberg]

You meant October 12? :)

Many of those are already listed in the Post-MVP doc in some form, I'll add the others.

3. initialize-once globals

I don't remember this one. What does it mean exactly?

[zapashcanon]

With @chambart we're going to present our freezable/sealable proposal at the next CG meeting.

It allows to have mutable and/or nullable globals/values only during initialization phase and they become immutable and/or non-nullable after this.

initialize-once globals

It may be one of the things we are proposing.

[fitzgen]

Another post-MVP feature to consider would be a way to compare funcrefs for equality and/or get unique IDs for them or something.

Then I could do speculative inlining of funcrefs as a Wasm-to-Wasm pass in Winliner instead of only for call_indirects through tables that are never mutated.

[jakobkummerow]

a way to compare funcrefs for equality

I agree that this would be useful to have.

Implementation perspective: if we expect that repeated creations of funcrefs for the same function index have distinct identity (in other words, that (ref.eq (ref.func $x) (ref.func $x)) evaluates to 0), then that would be annoying/inefficient to implement. If we specify that funcrefs are implicitly cached/canonicalized, i.e. there is only one unique funcref returned by arbitrarily many executions of (ref.func $x) for a given $x, then that would be trivial to implement -- in fact, we already make use of this property (and pointer-equality comparisons based on it) internally in V8.
(To be fair, I cannot say with certainty whether other engines might see this differently, but I would find that somewhat surprising: the obvious way how to make ref.func fast is to cache or even pre-initialize its result, so it doesn't need an allocation every time.)

[rossberg]

One of the known problems with function identity is that it invalidates optimisations like specialisation or any code transformation duplicating/merging function definitions that are referenced.

[kripken]

Previous discussion on function comparisons: #239 , some use cases and data there from a year ago.

Overall I think this can help in the toolchain, as @fitzgen said, but I also agree with @rossberg that the downsides need to be carefully weighed here. Another thing to consider is that if VMs inline at runtime then this probably becomes less important, and for that reason I don't consider this high priority personally.

[fitzgen]

Another thing to consider is that if VMs inline at runtime then this probably becomes less important

FWIW, not all engines / Wasm environments have (or will ever have) JIT capabilities.