Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add throwing instructions and funcref equality to Post-MVP #340

Merged
merged 2 commits into from
Nov 16, 2022
Merged
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
16 changes: 16 additions & 0 deletions proposals/gc/Post-MVP.md
Original file line number Diff line number Diff line change
Expand Up @@ -21,6 +21,7 @@ See [overview](Overview.md) for addition background.
* [Weak references](#weak-references)
* [Method dispatch](#method-dispatch)
* [Handle nondefaultable fields in `struct.new_default`](#handle-nondefaultable-fields-in-structnew_default)
* [Throwing versions of trapping instructions](#throwing-versions-of-trapping-instructions)

## Bulk Operations

Expand Down Expand Up @@ -773,3 +774,18 @@ The problem could be addressed by extending the type system with features that a
As proposed in #174. The idea is that `struct.new_default` would take values for nondefaultable fields in the struct from the stack. This would be a code size optimization over having to specify every single field with `struct.new` when allocating a struct containing nondefaultable fields.

**Why Post-MVP:** This is a local code size optimization that does not affect expressivity, so getting it into the MVP is not urgent.


## Throwing versions of trapping instructions

Some language implementers have expressed interest in having throwing versions of operations like `struct.get` to simplify the implementation of e.g. Java's `NullPointerException`. It may be worth investigating what the potential code size or performance benefits of these instructions would be. See [#208](https://github.com/WebAssembly/gc/issues/208) for details and previous discussion.

**Why Post-MVP:** Null checks followed by throws are easily expressible in the MVP, so there is no pressing need to add additional instructions for this pattern.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would add here that this feature is dependent on the exception proposal.



## Equality-comparable funcref

Being able to compare function references for equality would enable more precise polymorphic devirtualization. On the other hand, some polymorphic devirtualization should already be possible by taking advantage of patterns in vtables and letting functions be equality comparable would inhibit function deduplication optimizations. See [#239](https://github.com/WebAssembly/gc/issues/239) for details and previous discussion.

**Why Post-MVP:** The benefits of this change are unknown and would likely be small, so it's not urgent that we get this into the MVP.