This is a tracking issue for a post-MVP feature
It will be updated as the issue progresses.

Topic threads
Champion Ben Smith @binji
Status in progress
Phase Feature proposal
Linked issues WebAssembly/design#992, WebAssembly/design#950, WebAssembly/design#730, WebAssembly/design#485, WebAssembly/design#314, WebAssembly/design#300, WebAssembly/design#104
Linked repositories github.com/WebAssembly/threads

Details

Provide low-level buildings blocks for pthreads-style shared memory: shared memory between threads, atomics and futexes.

New atomic memory operators, including loads/stores annotated with their atomic ordering property, will follow a model compatible with the C++11 memory model (with some differences), similarly to the PNaCl atomic support and the SharedArrayBuffer support in JavaScript. Even when there are data races, WebAssembly will ensure that the nondeterminism remains limited and local.

There is ongoing work to formalize the memory model used by SharedArrayBuffer. This can be used by WebAssembly threads, since both JavaScript and WebAssembly are intended to be able to communicate through SharedArrayBuffer.

Really small request, but I'm sure that reinterpretation instructions that split/merge their values could efficiently be implemented on most platforms.

I suggest that the following be added to Wasm:

Consider this function:

(func (export "add") (param i64)
	local.get 0
	i32x2.reinterpret/i64
	i32.add
)

The body of that function would directly map to the following x64 Asm:

add eax, eax

But all the instructions would need to do is pop different amounts of bits from the VM's stack.
Technically, they could all be nops, that just change how an implementation validates instructions.

1. Will the functions consume stack value when it's been called if it has parameters?
2. What are the default value of the function locals if we call a local.get before calling local.set?

I see that the latest wat2wasm (version 1.0.24 for Windows) has an option --enable-function-references to enable Typed Function References. I tried it out on the test suite in proposals\function-references, extracting modules from .wast files by hand.

But it doesn't work -- (ref t$), let, br_if_null etc are not recognised. Is this going to be fixed? Or am I just doing something wrong?

This is a tracking issue for a post-MVP feature
It will be updated as the issue progresses.

Topic Garbage collection
Champion Andreas Rossberg (@rossberg-chromium)
Status In progress
Phase Feature proposal
Linked issues WebAssembly/design#985 WebAssembly/design#919 WebAssembly/design#733 WebAssembly/design#715 WebAssembly/design#484 WebAssembly/design#289 WebAssembly/design#238
Linked repositories github.com/WebAssembly/gc/

Details

To realize the high-level goals of (1) integrating well with the existing Web platform and (2) supporting languages other than C++, WebAssembly needs to be able to:

• reference DOM and other Web API objects directly from WebAssembly code;
• call Web APIs (passing primitives or DOM/GC/Web API objects) directly from WebAssembly without calling through JavaScript; and
• efficiently allocate and manipulate GC objects directly from WebAssembly code.

An important constraint is that, while WebAssembly should allow tight integration with the Web, it should not bake in details or Web standards dependencies that prevent execution in a
non-Web embedding. This suggests a design (called opaque reference types) that hides the details of JavaScript and WebIDL behind Web-embedding-specific builtin modules. On the other hand, WebAssembly can define a set of native GC primitives that allowed portable GC code to be written regardless of the host environment.

In #16 there is a broken link for "high-level goals" in the details section. I believe it should point here:
https://github.com/WebAssembly/design/blob/master/HighLevelGoals.md

At #6 (comment) @chicoxyzzy asks

Should we remove this proposal from proposals list? It seems that it was superseded by typed function references proposal

Although the proposal is assigned to me, I am apparently not a "collaborator" as I see

This conversation has been locked and limited to collaborators.

Please make me a collaborator so I can comment about my own proposal. Thanks.

Reading over the proposals the phase tags are a great way to get a high-level idea about where a proposal is in the process, but one thing I've found that's somewhat difficult to figure out is the actual concrete implementation status. While the phases imply some degree of implementation, I've found it also nice to know the concrete status in various engines.

For example, SIMD is implemented Node, but it disagrees with LLVM's opcode definitions. Bulk memory operations have recently been implemented in Firefox, but are currently temporarily diverged from the spec in terms of encoding. Atomic instructions and SharedArrayBuffer seem to be implemented in a lot of places!

Would it be possible to have a section either on each proposal itself (in the proposal repository) or in this tracking repository (via the issues or the README) to have a location to edit about the current status? This may also be a bit of a pipe dream because these sorts of statuses are notoriously hard to keep up to date.

This is largely motivated from a desire to test out reference types especially because it's in phase 3 which seems much farther along than many other proposals! At the outset though I don't actually know where I could test it (Firefox? Node? Chome? Safari?) and I'll be digging into various engines to see implementation statuses. For example I know Firefox doesn't support anyref tables right now, but that was learned through other means!

Do others feel like it's possible to do this? I'd also be fine ruling this under "there's so few people this'd apply to it's not worth the effort", as that seems totally reasonable to me!

I'm currently the champion of the extended name section proposal, but I haven't had a chance to work on it for years, and would like to hand it off to somebody who can get it moving again.

These can be helpful for quickly performing operations on the stack without extra usage of local variables.

We are develop an app using electron, but our app need use opencv to run our deep learning algorithms (base C++). Can WebAssembly call a dll to finish this?

This is a tracking issue for a post-MVP feature
It will be updated as the issue progresses.

Topic C/C++ API
Champion Andreas Rossberg @rossberg
Status in progress
Phase Feature Proposal
Linked repositories https://github.com/rossberg/wasm-c-api

Details

Unfortunately I was not able to follow all TPAC changes. Which of these proposal has been advanced?

Tail calls advance to stage 3
C/C++ API advance to stage 1
Bulk Memory Operations to stage 2

This is a tracking issue for a post-MVP feature
It will be updated as the issue progresses.

Topic Tail call
Champion Andreas Rossberg @rossberg
Status in progress
Phase Feature proposal
Linked issues WebAssembly/design#936, WebAssembly/design#189, WebAssembly/design#484,
Linked repositories github.com/WebAssembly/tail-call

Details

• Currently, the Wasm design explicitly forbids tail call optimisations

• Want support to enable

  • the correct and efficient implementations of languages that require tail call elimination
  • the compilation of control constructs that can be implemented with it (e.g., forms of coroutines, continuations)
  • compilation and optimization techniques that require it (e.g., dynamic recompilation, tracing, CPS)
  • other sorts of computation being expressed as Wasm functions, e.g., FSMs

This is a tracking issue for a post-MVP feature
It will be updated as the issue progresses.

Topic Multi-value
Champion Andreas Rossberg @rossberg
Status in progress
Phase Implementation phase
Linked issues WebAssembly/design#937, WebAssembly/design#667,
Linked repositories github.com/WebAssembly/multi-value)

Details

• Multiple return values for functions:

  • enable unboxing of tuples or structs returned by value
  • efficient compilation of multiple return values

• Multiple results for instructions:

  • enable instructions producing several results (divmod, arithmetics with carry)

• Inputs to blocks:

  • loop labels can have arguments
  • can represent phis on backward edges
  • enable future pick operator to cross block boundary
  • macro definability of instructons with inputs
    • i32.select3 = dup if ... else ... end

In WebAssembly/exception-handling#145, it was pointed out that exception-handling and function-references were both using 0x16. Perhaps a central list of proposed opcodes would help prevent that in the future.

As I am looking into the Multi-value proposal, and just wondering to know how I can access the input parameters of an "if" structure?

(func $xxxx (param i64 i64) (result i64)
;; ....
	(if (param i64) (result i64)
		;; how can I access the input param of the outer if structure here?
	)
)

The stack store instructions take arguments like this: [pointer, value]. However, if the arguments were in the order [value, pointer], it would be easier to use the store instructions with long data structures on the stack. Of course, making this change would break backwards compatibility, so a "reverse" or "swap" instruction that reverses the last two values on the stack could address this.

I can't elaborate on this point right now, but if you also faced this, you'll probably know what I'm talking about.

This is a tracking issue for a post-MVP feature
It will be updated as the issue progresses.

Topic Bulk memory operations
Champion Ben Smith @binji
Status in progress
Phase Feature proposal
Linked issues WebAssembly/design#236 WebAssembly/design#977 WebAssembly/design#1057
Linked repositories bulk-memory-operations

Details

Copying and clearing large memory regions is very common, and making these
operations fast is architecture dependent. Although this can be done in the MVP
via i32.load and i32.store, this requires more bytes of code and forces VMs
to recognize the loops as well. The following operators can be added to improve
performance:

• move_memory: Copy data from a source memory region to destination region;
  these regions may overlap: the copy is performed as if the source region was
  first copied to a temporary buffer, then the temporary buffer is copied to
  the destination region
• set_memory: Set all bytes in a memory region to a given byte

We expect that WebAssembly producers will use these operations when the region
size is known to be large, and will use loads/stores otherwise.

This is a tracking issue for a post-MVP feature
It will be updated as the issue progresses.

Topic Reference Types
Champion Andreas Rossberg (@rossberg)
Status In progress
Phase Implementation Phase
Linked issues
Linked repositories https://github.com/WebAssembly/reference-types

This is a tracking issue for post-MVP work
It will be updated as the issue progresses.

Topic WebAssembly specification
Champion Andreas Rossberg (@rossberg-chromium)
Status In progress
Phase Proposed spec text available
Linked issues none
Linked repositories github.com/WebAssembly/spec

Details

Formalize the WebAssembly specification including:

• Reference interpreter

• Test suite

• English and formalized description of WebAssembly including:

  • Structure of values, types, instructions, and modules
  • Validation
  • Execution
  • Binary Format
  • Text format
  • JavaScript APIs and Web embedding

This is a tracking issue for a post-MVP feature
It will be updated as the issue progresses.

Topic Content Security Policy
Champion none
Status in progress
Phase Feature proposal
Linked issues WebAssembly/design#1092 WebAssembly/design#205 WebAssembly/design#972
Linked repositories github.com/WebAssembly/content-security-policy

Details

Details

Content Security Policy (CSP) is an added layer of security that helps to detect and mitigate certain types of attacks, including Cross Site Scripting (XSS) and data injection attacks. These attacks are used for everything from data theft to site defacement or distribution of malware.

In the context of WebAssembly, CSP can:

• Forbid usage of WebAssembly for developers who opted in to CSP before WebAssembly existed.
• Allow finer-grained control of JavaScript restrictions (including unsafe-eval) versus WebAssembly using new CSP mechanisms.

References:

• MDN description of CSP
• @jfbastien has a first proposal covering CSP as implemented in WebKit.
• This was discussed in the 08-08 video call. A poll encouraged @flagxor to work on this.
• Some folks mentioned Sub-Resource Integrity along with CSP.

This is a tracking issue for a post-MVP feature
It will be updated as the issue progresses.

Topic Type Reflection for WebAssembly JavaScript API
Champion Till Schneidereit @tschneidereit
Status in progress
Phase feature proposal
Linked issues WebAssembly/threads#87 WebAssembly/design#1046
Linked repositories github.com/WebAssembly/js-types/blob/master/proposals/js-types

Details

WebAssembly is typed, and its types carry information that can be useful and important to clients interacting with WebAssembly modules and objects through the JavaScript API. For example, types describe the form of imports and exports, including the size limits of memories and tables or the mutability of globals.

Can we provide a mode to make floating point support optional? The compiler should just use soft float.

This is important for translating wasm to vanilla lua for example where you do not have proper float point support.

Since Wasm is finding use cases outside the browser perhaps the name can be rethought to reflect this. Also this means all the non browser use cases also considered early in designs and in proposals.

Based on the docs here, I think GC is in the specification phase. However, as Microsoft has released Blazor WebAssembly, I think that WA has some GC already implemented. Am I right? What GC features does WASM already have?

It will be easier to reference changes from versioned docs if the affected docs (core, js-api, web-api) are listed in a column next to the date

Whats the idea behind the specification proposal phases?
Do they correlate with release versions of the specification i.e Phase 1 bundles all proposals planned to be released in version 1 etc?
Also is there a planned release schedule for the specification or is the specification updated as soon as any given proposal is passed?

There are a lot of dll modules (500+) that exist in our corp already that most of them written in C++ ( compile from VC 6 ~ latest) and some of them have SIMD/OpenCL/DirectX ... hardware acceleration, some of them have a long history and not possible to recompile them at all, some of them are load by other dll and some may provided by other company like Intel, ... etc. But I don't found any document that describe how it possible to integrate these modules into WebAssembly. A wrapper?

Of course I don't assume I can use them all, part of them can integrate without problem is already great for me.

Is it possible to create a platform depend wrapper then integrate these modules into WebAssembly?

If the answer is yes, please tell me where to find the reference?

Or this is the future feature, or it's not possible to happened in WebAssembly?

On https://www.chromestatus.com/features#webassembly some of the tracking bugs are not publicly accessible, for example https://bugs.chromium.org/p/chromium/issues/detail?id=840415. Is this intentional?

I create a main branch on origin, and with WebAssembly/spec#1368 we should flip the default to main on this repository too. I will upload a PR to change all the pointers to master in this repository.

For the sake of having a good overview of all our proposals, I would suggest putting the table of finished proposals inline at the top of this page rather than linked: https://github.com/WebAssembly/proposals

For example, I was scanning the list and thinking.. wait, what stage is multi-value? Until I realized where it was hiding. To some extend "finished" is also a stage :) For most people not intimately familiar with our proposals it is mostly important to see what is all in the pipeline, and even "finished" proposals are not necessarily available in all implementations yet, so remain relevant there.

If ever the list of finished proposals gets crazy long the current structure would maybe make more sense, but we're in no danger of that happening any time soon.

Inactive proposals can remain a link, but I would put them at the end of the document, which would be more logical if everything is ordered by "progress"

See comment here: #38 (comment)

• Create new repository, forked from https://github.com/WebAssembly/spec
• Update WebAssembly/proposals repo
• Create tracking issue (e.g. #39)
• Enable Travis CI for repo: https://travis-ci.org/account/repositories
• Enable WebHooks: https://github.com/WebAssembly/mynewproposal/settings/hooks
• Update deploy_key.enc: https://github.com/WebAssembly/reference-types/settings/keys
  • See https://gist.github.com/domenic/ec8b0fc8ab45f39403dd
  • TODO: use https://docs.travis-ci.com/user/deployment/pages/ instead?
• Add champion as owner/collaborator of repo: https://github.com/WebAssembly/mynewproposal/settings/collaboration

This is a tracking issue for a post-MVP feature
It will be updated as the issue progresses.

Topic Fixed-width SIMD
Champion @PeterJensen, @aretmr
Status in progress
Phase Feature proposal
Linked issues WebAssembly/design#148, WebAssembly/design#41
Linked repositories github.com/WebAssembly/simd

Details

Support fixed-width SIMD vectors, initially only for 128-bit wide vectors as demonstrated in PNaCl's SIMD and SIMD.js.

SIMD adds new local types (e.g., f32x4) so it has to be part of the core semantics. SIMD operators (e.g., f32x4.add) could be either builtin operators (no different from i32.add) or exports of a builtin SIMD module.

I there a way to directly use WebRTC from WASM yet? P2P-Chat is a typical use case for web apps, and it would be nice to be able to use WebRTC APIs without js interop.

Unfortunately as someone only barely touching the topic, it's very complicated to find a direct answer to this online, as there are no examples.

This is a tracking issue for a post-MVP feature
It will be updated as the issue progresses.

Topic Non-trapping float-to-int conversions
Champion Dan Gohman @sunfishcode
Status in progress
Phase Implementation phase
Linked issues WebAssembly/design#986, WebAssembly/design#1089
Linked repositories github.com/WebAssembly/nontrapping-float-to-int-conversions

Details

The primary motivations are:

• LLVM’s float-to-int conversion has an undefined result, rather than undefined behavior, and it seems LLVM does speculate it under certain conditions.
• For the SIMD proposal, it’s more SIMD-hardware-like if no SIMD operations trap. This proposal would establish a convention for saturating operations which SIMD could share, to avoid introducing trapping.

This proposal is not motivated by performance data.

It's plausible that LLVM could be changed, to have something like an "nsw" flag for the "fptosi" instruction, especially with some of the recent proposals to modify the poison concept in LLVM. However, no one is currently working on this.

This is a tracking issue for a post-MVP feature
It will be updated as the issue progresses.

Topic Import/Export of Mutable Globals
Champion Ben Smith @binji
Status in progress
Phase standardize
Linked issues
Linked repositories github.com/WebAssembly/mutable-global

Details

Imported and exported globals can now be mutable. In the Web binding, exported globals are now of type WebAssembly.Global, rather than converted to a JavaScript Number.

I am sorry if this is not the right repository to report, but:

• Extended constant expressions was shipped and enabled by default in Firefox 90 (Bug 1706124) 112 (Bug 1814421)
• GC is available in Firefox Nightly, requiring the javascript.options.wasm_gc flag to enable

This is a tracking issue for a post-MVP feature
It will be updated as the issue progresses.

Topic Function References
Champion Andreas Rossberg (@rossberg)
Status In progress
Phase Feature Proposal
Linked issues
Linked repositories https://github.com/WebAssembly/function-references

The link on issue #10 should link to https://github.com/WebAssembly/reference-types

This is a tracking issue for a post-MVP feature
It will be updated as the issue progresses.

Topic WebIDL bindings
Champion Luke Wagner @lukewagner
Status in progress
Phase Feature proposal
Linked issues
Linked repositories github.com/WebAssembly/interface-types

Details

Efficient bindings to host objects and functions.

WebAssembly has a significant backwards compatibility constraint. It is also exploring an almost entirely new space and solving very hard problems requiring substantial design and implementation work. As such, it is important to make sure that any designs developed, implemented, and shipped have been substantially evaluated on whether they achieve their intended purpose. To this end, I suggest the following amendment to the process:

As a requirement for advancing to Stage 3, every feature of the proposal should have approval from a substantial user base (where the appropriate scale/meaning of "substantial" and "user base" depends on the specifics of the proposal).

There are two primary reasons for this revision:

1. We cannot evaluate whether the proposal's design for a feature effectively achieves its intended goal without a substantial user base to either demonstrate its utility or to provide feedback on how the proposal needs to be revised to meet their needs.
2. As much of that evaluation should be done prior to implementation to reduce churn due to design changes.

With this requirement in place, when the reference types proposal went to Stage 3 we would have seen that, although external references had a big user base, subtyping did not and so should be carved out into a separate proposal. Furthermore, this separation would have made it apparent that many other proposals do not need to depend on the reference types proposal. Many uses of type imports do not need any constraints at all (arguably external references are an example of this), and alternative (even more expressive) constraints besides subtyping could be explored. Although exception handling uses exnref, which might represent uninterpretable exceptions depending on the host, there is no requirement that exnref be related to external references. Even garbage collection does not depend on anyref or external references; we demonstrated that even languages relying on a uniform representation would generally prefer to use a uniform representation that is specialized to the needs of the language over a useless type like anyref. So the separation this requirement would have encouraged would have also reduced the dependencies between proposals.

But pulling back from the current situation, what do y'all think of the proposed revision that every feature of a Stage 3 proposal should have enough demand to warrant implementation and to enable proper evaluation?

[This was substantially edited thanks to feedback from @jgravelle-google.]

After the recent CG meeting (TODO: link notes once uploaded), we need to pin down how we're advancing the intertwined Relaxed SIMD and Profiles proposals - we previously determined that Relaxed SIMD would have a dependency on the existence of a "deterministic" profile.

Here's my view on how votes for moving these forward should be structured:

• We should vote on relaxed SIMD to phase 4 in the in-person meeting. This vote will imply editorial changes to the spec to create the syntactic framework for profiles and exactly two profiles ("full" and "deterministic") - the poll question can reflect this. No procedural mechanism will be established for adding any further profiles.

• The profiles "proposal" should be interpreted as a consensus vote on establishing new procedure to evaluate and introduce future profiles - such as the suggested "no-gc" profile. Maybe this means that it shouldn't be called a proposal any more, but simply a vote on a procedural change - a more ambitious version of our previous phase advancement process changes. This debate+vote may take longer to work through (see WebAssembly/profiles#6), and the relaxed SIMD vote above does not depend on it.

In the case that the first vote passes but the latter process never completes, this would result in "full" and "deterministic" indefinitely being the only profiles in the specification.

This is a tracking issue for a post-MVP feature
It will be updated as the issue progresses.

Topic Unmanaged Closures
Champion Mark Miller @erights
Status withdrawn
Phase pre-proposal
Linked issues
Linked repositories

• https://github.com/WebAssembly/unmanaged-closures
• https://github.com/erights/wasm-linkage/tree/master/proposals/wasm-linkage

Details

Many applications are extensible frameworks, built to accept third party plugins that add value. For example, Photoshop accepts third party plugins for image transformations. Google EarthEngine is a web-based application that accepts third party plugins for geospatial computation. Many of these plugins are fallible; EarthEngine wishes to protect its own integrity from the potential corruption or compromise of its plugins. At the same time, EarthEngine needs to expose a rich API to these plugins so that they can interact flexibly with EarthEngine. Currently, EarthEngine is written in JavaScript and enforces that its plugins are written in SES (Secure EcmaScript) an ocap subset of JavaScript.

Wasm would enable EarthEngine to be written in C++, and to accept plugins written in C++. Wasm already provides all the protection mechanisms needed so they can be linked together in one OS address space and interact via full speed function calls. EarthEngine would reside in one compartment (a set of wasm modules linked together sharing the same memories and tables --- see below) and each plugin in another. EarthEngine would export the functions it wishes to make available to its plugins, and instantiate each plugin only with access to these exports. The code within each compartment is as vulnerable to buffer overflow or other memory corruption as we expect of C++. But this separation prevents a memory corruption vulnerability in a plugin from compromising EarthEngine.

In this sense, each wasm compartment resembles an OS process with its separate address space and descriptors; and an inter-compartment call resembles an IPC. However, the cost of the context switch between these protection domains is simply the cost of code in one wasm compartment calling an imported function that was exported by another linked wasm compartment.

This demonstrates that wasm already provides the safety needed for such protection. But it lacks the needed expressiveness.

This is a tracking issue for a post-MVP feature
It will be updated as the issue progresses.

Topic ECMAScript module integration
Champion Lin Clark @linclark and Daniel Ehrenberg @littledan
Status Not started
Phase feature proposal
Linked issues WebAssembly/design#997 WebAssembly/design#972 WebAssembly/design#969 WebAssembly/design#657 WebAssembly/design#252 WebAssembly/design#119
Linked repositories esm-integration

Details

WebAssembly programs are currently represented through a WebAssembly.Module, which can be instantiated as WebAssembly.Instance. Both of these present themselves as regular JavaScript objects which don't interact with ECMAScript modules (both the static modules in ES6 as well as proposed dynamic module loading).

While ES6 defines how to parse, link and execute a module, ES6 does not define when this parsing/linking/execution occurs. An additional extension to the HTML spec is required to say when a script is parsed as a module instead of normal global code. This work is ongoing.

Currently, the following entry points for modules are being considered:

• <script type="module">;
• an overload to the Worker constructor;
• an overload to the importScripts Worker API;

Additionally, an ES6 module can recursively import other modules via import statements.

For WebAssembly/ES6 module integration, the idea is that all the above module entry points could also load WebAssembly modules simply by passing the URL of a WebAssembly module. The distinction of whether the module was WebAssembly or ES6 code could be made by namespacing or by content sniffing the first bytes of the fetched resource (which, for WebAssembly, would be a non-ASCII—and thus illegal as JavaScript—magic number).

Thus, the whole module-loading pipeline (resolving the name to a URL, fetching the URL, any other loader hooks) would be shared and only the final stage would fork into either the JavaScript parser or the WebAssembly decoder.

Any non-builtin imports from within a WebAssembly module would be treated as if they were import statements of an ES6 module. If an ES6 module imported a WebAssembly module, the WebAssembly module's exports would be linked as if they were the exports of an ES6 module. Once parsing and linking phases were complete, a WebAssembly module would have its start function, defined by the start module option, called in place of executing the ES6 module top-level script. By default, multiple loads of the same module URL (in the same realm) reuse the same instance. It may be worthwhile in the future to consider extensions to allow applications to load/compile/link a module once and instantiate multiple times (each with a separate linear memory).

This integration strategy should allow WebAssembly modules to be fairly interchangeable with ES6 modules (ignoring GC/Web API 🦄 future feature signature restrictions of the WebAssembly MVP) and thus it should be natural to compose a single application from both kinds of code. This goal motivates the semantic design of giving each WebAssembly module its own disjoint linear memory. Otherwise, if all modules shared a single linear memory (all modules with the same realm? origin? window?—even the scope of "all" is a nuanced question), a single app using multiple independent libraries would have to hope that all the WebAssembly modules transitively used by those libraries "played well" together (e.g., explicitly shared malloc and coordinated global address ranges). Instead, the dynamic linking future feature is intended to allow explicitly sharing state between module instances.

This is a tracking issue for a post-MVP feature
It will be updated as the issue progresses.

Topic Sign-extension operators
Champion Ben Smith @binji
Status in progress
Phase standardize the feature
Linked issues
Linked repositories github.com/WebAssembly/sign-extension-ops

Details

This proposal adds five new integer instructions for sign-extending 8-bit, 16-bit, and 32-bit values.

• i32.extend8_s: extend a signed 8-bit integer to a 32-bit integer
• i32.extend16_s: extend a signed 16-bit integer to a 32-bit integer
• i64.extend8_s: extend a signed 8-bit integer to a 64-bit integer
• i64.extend16_s: extend a signed 16-bit integer to a 64-bit integer
• i64.extend32_s: extend a signed 32-bit integer to a 64-bit integer

This is a tracking issue for a post-MVP feature
It will be updated as the issue progresses.

Topic Exception handling
Champion Heejin Ahn (@aheejin)
Status In progress
Phase Feature proposal
Linked issues WebAssembly/design#417
Linked repositories github.com/WebAssembly/exception-handling

Details

The WebAssembly MVP supports four no-exception modes for C++:

• Compiler transforms throw to abort().
• Compiler-enforced -fno-exceptions mode (note caveats).
• Compiler conversion of exceptions to branching at all callsites.
• In a Web environment exception handling can be emulated using JavaScript exception handling, which can provide correct semantics but isn't fast.

These modes are suboptimal for code bases which rely on C++ exception handling, but are perfectly acceptable for C code, or for C++ code which avoids exceptions. This doesn't prevent developers from using the C++ standard library: their code will function correctly (albeit slower at times) as long as it doesn't encounter exceptional cases.

Post-MVP, WebAssembly will gain support for zero-cost exception handling.

In turn, this can be used to implement setjmp/longjmp, and can enable all of the defined behavior of setjmp/longjmp, namely unwinding the stack without calling C++ destructors. It does not, however, allow the undefined behavior case of jumping forward to a stack that was already unwound which is sometimes used to implement coroutines. Coroutine support is being considered separately.

This is a tracking issue for a post-MVP feature
It will be updated as the issue progresses.

Topic JavaScript BigInt to WebAssembly i64 integration
Champion Dan Ehrenberg @littledan
Status in progress
Phase proposed spec text available
Linked issues WebAssembly/spec#707
Linked repositories github.com/WebAssembly/JS-BigInt-integration

Details

With this patch, BigInts have support for bidirectionally converting
to 64-bit integer WebAssembly values, which appears as

• Parameters and return values to exported WebAssembly functions
• Parameters and return values to host functions
• Imported and exported globals

BigInts can be read or written from WebAssembly memory using the
BigInt proposal's BigInt64Array or BigUint64Array; no additional
support is needed.

This is a tracking issue for a post-MVP feature
It will be updated as the issue progresses.

Topic Custom Annotation Syntax in the Text Format
Champion Andreas Rossberg @rossberg
Status in progress
Phase feature proposal
Linked issues none
Linked repositories github.com/WebAssembly/annotations

Details

• The Wasm binary format supports custom sections to enable associating arbitrary meta data with a Wasm module.
• No equivalent exists for the text format. In particular, there is no way to
  • represent custom sections themselves in the text format, cf. WebAssembly/design#1153 and https://gist.github.com/binji/d1cfff7faaebb2aa4f8b1c995234e5a0
  • reflect arbitrary names in the text format, cf. WebAssembly/spec#617
  • express information like for host bindings, cf. https://github.com/WebAssembly/host-bindings/blob/master/proposals/host-bindings/Overview.md
• This proposal adds the ability to decorate a module in textual notarion with arbitrary annotations of the form (@id ...).
• Neither the syntactic shape nor the semantics is prescribed by the Wasm specification, though the Appendix might include a description of optional support for name section annotations and generic custom sections.
• This proposal only affects the text format, nothing else.