#1002: Review for CR transition of WebAssembly specifications for version 2.0 features

Visit on Github.

Opened Oct 8, 2024

こんにちは 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²: https://github.com/WebAssembly/spec/issues/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.

Discussions

2024-10-14

Minutes

punted

2024-10-21

Minutes

Martin: I don't think this is a problem. the reference types explainer has not been updated... maybe the spec is up to date, but the explainer is not ready. there is a naming problem... Otherwise it would be keep up the good work.

Matthew: the repo is officially abandoned...

Martin: the question is where is the material?

Martin: writes proposed comment:

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.

2024-10-28

Minutes

Dan: we got a response.

Matthew: they said "yes it's part of our work mode" ... but they did point out that there is a design rationale docs posted publicly...

Martin has suggested that we close. We have +1's on that from Jeffrey, Tess, Yves, Matthew, Dan

Hi and thank you for your response, @dschuff. 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.

closed