Review for CR transition of WebAssembly specifications for version 2.0 features

[dschuff]

こんにちは TAG-さん!

I'm requesting a TAG review of WebAssembly 2.0.

This is a request for transition for version 2.0 of all 3 WebAssembly specifications, namely the core spec, which defines the core code format and semantics;
the JS API specification, which provides a JavaScript API for interacting with WebAssembly; and the Web API specification, which describes the integration of WebAssembly with the broader web platform.

For review convenience, here is a list of the explainers for the proposals that have gone into 2.0, compared to 1.0 (currently in REC state). These are informal descriptions of the proposed changes and are not canonical, but describe an overview of the feature and could be useful in determining whether there is anything of interest for horizontal reviewers.

Note also that the specifications contain change history sections summarizing additions to each spec (core, JS, Web)
listing and summarizing additions since version 1.0. The table summarizes the effect on the JS spec. The Web spec is unchanged since 1.0

Explainer	Specs affected
Nontrapping float-int conversion	Core
Sign-extension operators	Core
Multi-value block and function returns	Core, JS
JS BigInt Integration	JS
Reference Types	Core, JS
Bulk Memory and table instructions	Core
SIMD Vector instructions	Core

• WPT Tests: The Core tests live in the spec repo (with a mirror here). The JS API tests are canonically here but are mirrored to WPT.
• User research: N/A, but our process does require implementation feedback from toolchain authors (as Wasm code is generated by toolchains)
• Security and Privacy self-review²: Self-review of security and privacy questionnaire for 2.0 CR transition WebAssembly/spec#1830
• GitHub repo: https://github.com/WebAssembly/spec
• Primary contacts:
  • Derek Schuff (@dschuff), Google, WG/CG co-chair
  • Andreas Rossberg (@rossberg), Independent, spec editor
  • Luke Wagner (@lukewagner), Fastly, WG co-chair
  • Thomas Lively (@tlively), Google, CG co-chair
  • Conrad Watt (@conrad-watt), NTU, CG co-chair
• Organization/project driving the specification: Spec graduates from WebAssembly CG to WG according to our process
• Multi-stakeholder support³:
  • All 4 major browsers have shipped all of the proposals in WebAssembly 2.0 (versions listed here ... I can give more details if you want)

Further details:

• I have reviewed the TAG's Web Platform Design Principles
• Relevant time constraints or deadlines: No deadline, but please review ASAP, as we have another batch of features to merge into the spec, and we hope to be more timely about that than we were about this one.
• The group where the work on this specification is currently being done: WebAssembly CG and WG
• The group where standardization of this work is intended to be done (if different from the current group): WebAssembly WG
• Major unresolved issues with or opposition to this specification: None
• This work is being funded by: Many organizations.

[martinthomson]

Hi @dschuff, we're looking at these and for the most part these seem reasonable, but we noted that the reference types explainer is full of questions and has a big TODO. Then we realized that most of the explainers are old and no longer being updated.

It seems like the WG work mode involves forking the spec for a feature and then archiving the fork once the changes are merged. However, this means that the explainers are sometimes not updated to include the sort of stuff the TAG likes to see, little things like user benefit (see our explainer explainer for more). Is there anywhere that we can get up-to-date information in that form? None of us are particularly expert at reading WASM specs, so it's hard to find these features, let alone find a discussion about benefits and trade-offs.

[dschuff]

Unfortunately there isn't such a convenient document. Reference types is actually especially bad in this respect (i.e. listing the design considerations in isolation) because it was carved out of the GC proposal as a prerequisite. The explainer for GC has more background (and details in the GC MVP); the rationale was basically to pull out a very minimal subset (the concept of a reference type, as well as the externref type and the allowance for multiple tables) to go through the process first.

[martinthomson]

Thanks for pointing to the GC docs, those definitely help.

Personally, I find the need to document things like user benefit as less acute for WASM. It was worth asking though. It's a bit of a shame that the documentation created during the development of features is ultimately lost. Having a well-maintained set of that sort of documentation is expensive, so it's understandable how things end up in this state.

[dschuff]

Yeah, we worked on documenting things like design rationale in the early days, but haven't really kept it up with every proposal as we've added them. User benefit is of course different (as wasm would be mostly transparent to end users) but every proposal has to consider e.g. developer benefit as it goes through the phases. Usually when champions request phase advancement they make a presentation that covers the design and often includes use cases and benefit (especially in early stages) design rationale, notable changes, etc. Those are all posted publicly, so at bare minimum it would be pretty straightforward to collect those, with links to the meeting notes, somewhere more convenient. Maybe we could have champions do that when they advance to phase 4.

[torgo]

Hi and thank you for your response, @dschuff. We reviewed again today and we agree that making those design rationale docs more discoverable, as you suggested, would be a good idea. Other than that we are satisfied with the proposal. Thanks for allowing us to review.

[dschuff]

Thank you!