Reference types for phase 4?

[lars-t-hansen]

After going through the open issues, there appear to be two substantive core language issues (#55, #60), both of which can probably be postponed if we want to or if we can't find agreement quickly. There is one corner case (#40) that should probably be resolved in favor of current behavior, because sentiment in the discussion is tilting in that direction. The JS API also has a small number of mop-up issues that may or may not already be done (#9, #20, #22, #51); investigating. The remaining open issues are discussion items or feature requests that have been postponed.

The process document requires these for phase 4 (with my comments about status):

• Two or more Web VMs implement the feature.
  • Firefox is tracking the spec, as is Chrome, I believe. @mstarzinger?
• At least one toolchain implements the feature.
  • Don't know what the status is here. @alexcrichton @kripken @sbc100, comments?
• The formalization and the reference interpreter are usually updated
  • These seem fine to me, @rossberg do you believe we're complete, modulo issues listed above?
• Community Group has reached consensus in support of the feature.
  • We have to have a poll to gauge this

We may need to ship bulk memory at the same time, as the two proposals touch in various ways, but if anything that proposal is even closer to a shipping state.

[rossberg]

I'm afraid #31 is still open in terms of incorporating it into the proposal, see my latest comment there.

[gahaas]

Chrome/V8 is passing all spec tests at the moment.

[alexcrichton]

At least one toolchain implements the feature.

The Rust and WebAssembly toolchain, specifically wasm-bindgen, does have support for reference types. There is not native support in the Rust compiler itself (nor LLVM, although that is being worked on). The support in wasm-bindgen is definitely "MVP status" where it doesn't really exercise a huge amount of features of the reference types proposal, largely just growing tables and get/set in tables.

That being said though it is well tested (against Node) and should be ready to ship and/or promote to a stable feature of the toolchain! A lot of the surrounding tooling has support for it too such as wabt, Rust toolchain crates, etc.

[sbc100]

I'm hoping to land the final PRs in wabt to allow it to pass all the current spec tests today.

[aheejin]

I’m working on Binaryen support.

[tlively]

Binaryen support alone is enough to get AssemblyScript working, but I'm not sure what their roadmap is for supporting reference types. cc @dcodeIO who can supply more AssemblyScript information.

[dcodeIO]

AssemblyScript supports the opaque anyref type as implemented in Binaryen behind --enable reference-types, that is one can declare variables and function parameters of type anyref and pass these around. Limitations are that one can't currently store anyrefs in non-imported globals because we are missing a way to initialize them (thinking ref.null) before these are set for the first time, one can't compare them (ref.is_null, ref.eq) and there is no table support yet. Expectation is that we are overly thrilled to follow close as soon as the respective bits land in Binaryen :)

[rossberg]

I rebased this proposal on the bulk proposal and filled the gaps between the two. Also implemented declarative element segments (#31) and addressed remaining todos in core spec and interpreter.

Remaining technical tasks for phase 4:

• A couple of minor adjustments to the JS API spec ([js-api] WebAssembly.Table.prototype.grow and a fill value #22, [js-api] ToWebAssemblyValue signature change #51, [js-api] Update table API #67).
• Test generation for bulk instructions over multiple tables ([test] Bulk instructions with multiple tables #74).

Other than that, the main open issue is #69, which is recent and awaiting more feedback from @lukewagner.

[aheejin]

Toolchain support is not complete yet. Emscripten (including LLVM + Binaryen) has a partial support:

• LLVM: Does not have support yet, but no frontend languages generate reference types for now
• Binaryen: Has a partial support but lacks table instruction support for now. I don't think it takes too much time to add them, but I'm not sure it is gonna be done before the Feb CG meeting. Also needs to implement [spec/interpreter/test] Declarative element segments #73.

[eqrion]

The two major issues blocking this, #69 and #76, are now resolved. Spidermonkey has updated our implementation for the latest changes. At least one toolchain, wasm-bindgen, implements the spec and is up to date with the latest changes. I believe the reference interpreter is up to date with all agreed upon changes.

Are there any other issues that should block us from moving this feature to phase 4 now?

I see WebAssembly/design#1343 mentioned an impact on this proposal, but appears to have reached a conclusion that it doesn't need to block this proposal. Is that accurate @RossTate?

[RossTate]

Yep!

[rossberg]

I created a PR to add it tomorrow's agenda.