consider mentioning WebAssembly feature extensions

[jpiesing]

There's a list of WebAssembly feature extensions at https://webassembly.org/features/. We should consider mentioning some of these in the Snapshot.

There are 16 of them in 'phase 5' of which 10 are listed as implemented on all 3 browser codebases - our usual criteria.

Many of these feature extensions are merged into the main specification so including them may mean including a newer version.

[JohnRiv]

Thanks for bringing this to our attention. I've spent some time today researching WebAssembly spec development, and found in the notes from their WG meeting in June that the WASM WG intends to publish a CR of WASM 2 (for all 3 specs) and then never advance it to REC and instead maintain the CR as a Living Standard.

So that does indicate that support for any new WASM features added after 1.0 would ideally be specified in WMAS one way or another.

To handle that, a couple initial thoughts I have are we could either:

• do what we do with the WHATWG living standards and include a note to "(use this version or later)" (it appears the WASM WG currently does publish dated Working Drafts to specref that we could reference)
• List out the specific additional features of WASM that should be supported in addition to either the 1.0 specs or the first CR 2.0 specs

It's probably worth a discussion with the WASM Spec Editor and WG Chairs on how they recommend we reference the WASM specifications after 1.0. Their Feature implementation report is great to easily see what would meet our criteria, but unfortunately the majority of the links are to proposals and not the WASM spec itself, and I'm having difficulty mapping some of those proposals to where they are in the spec (Typed Function References is one example of that)

Since for WMAS2024 we intend to have to have the WASM remain in the "Web Media APIs proposed to be supported on all platforms" section, we can likely leave that untouched for this year (although happy to discuss additional text to include in WMAS2024 around this), but I do feel that discussion with WASM would be beneficial for both our group and theirs to have very soon.

[JohnRiv]

After reaching out to the WASM Editors & Working Group chairs, we've learned the WASM 2.0 specs as far as major features go have been in place since 2022 and those features have support of the 4 major browsers. Those specs are available at:

• https://www.w3.org/TR/wasm-core-2/
• https://www.w3.org/TR/wasm-web-api-2/
• https://www.w3.org/TR/wasm-js-api-2/

Those are currently working drafts, with the expectation they will go to Candidate Recommendation in the somewhat near future.

WASM 2.0 includes these Feature Extensions:

• JS BigInt to Wasm i64 Integration
• Bulk Memory Operation
• Multi-value
• Reference Types
• Non-trapping float-to-int Conversions
• Sign-extension Operators
• Fixed-width SIMD

These additional Feature Extensions with support of all 3 browsers are slated for WASM "3.0" (or at least some sort of incremental version from 2.0):

• Extended Constant Expressions
• Import/Export of Mutable Globals (my mistake, they're actually in 1.0)
• Typed Function References

So given that, we could at a minimum update our non-normative WASM 1.0 references to WASM 2.0. In addition we could add additional notes around those 2 additional WASM features, although the only reference docs for those are the proposals in GitHub or this PDF draft of WASM 3.0 in GitHub: https://webassembly.github.io/spec/versions/core/WebAssembly-3.0-draft.pdf

[JohnRiv]

In the WAVE HATF call today, we agreed to update the WASM reference to 2.0, as well as add a note mentioning the other 3 features

[JohnRiv]

I've staged a PR for review at #366 based on our discussions. In doing so, I realized there were only 2 additional features we had to add to the note (Import/Export of Mutable Globals made it into 1.0)

[matt-hammond-001]

I've been thinking about the two feature extensions that go beyond 2.0 and I'm wondering if Typed Function References should be removed?

Extended Constant Expressions appear to have been implemented for sometime now, are widely supported in tooling and are part of the lime1 configuration that the WASM CG are establishing But Typed Function References look like they have only been widely implemented for about 1 year and therefore might be more challenging for some to adopt.

Typed Function References appear to be closely related to garbage collection. I'm wondering if it has significant utility when the GC feature extension is not included.

There are some tool chains that seem to use it, but maybe only because they need garbage collection for directly compiling high level garbage collected languages? For example: kotlin/wasm appears to compile directly to WASM rather than compiling a C based runtime environment that would implement its own internal GC (see Chrome developer blog explanation here)

There doesn't appear to be any imminent support in emscripten / LLVM. Maybe this makes sense given C/C++ not generally having garbage collection.

[JohnRiv]

Thanks @matt-hammond-001 for your feedback. You raise good points, and I think it makes sense to not include Typed Function References for now. They were a recent addition to Safari (added in v18.0, which was released in September 2024), and to your point might be more challenging for some to adopt that quickly.

I'll update my PR to remove that reference, and I welcome additional input.

[matt-hammond-001]

Thanks @JohnRiv.

Thinking longer term: GC support does sound like it will eventually be useful once it has become more established. The ability to compile down from higher level languages and hopefully see significant performance improvements might provide useful options for more efficient (and reliable) application development. The likes of C/C++ is not to everybody's taste.