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

Change exactness prefix opcode? #23

Open
tlively opened this issue Mar 21, 2025 · 1 comment
Open

Change exactness prefix opcode? #23

tlively opened this issue Mar 21, 2025 · 1 comment

Comments

@tlively
Copy link
Member

tlively commented Mar 21, 2025

0x62 made sense as the next opcode in the reftype production. In the heaptype production the next available opcode is 0x69. But also we might want to leave the 0x6x range entirely available for future abstract heap types? Perhaps 0x5F would then start a new category for heap types prefixes?

Originally posted by @sjrd in #18 (comment)

@jakobkummerow
Copy link
Contributor

0x69 is exnref.
0x68 is contref.
0x67 is stringref currently, though that could be moved elsewhere given its lack of momentum, just like stringview_wtf16 had to move to free up 0x62.

Using 0x5F is an easy way to avoid collisions -- as long as this is the only proposal that thinks "hey, we have an entire unused 0x5_ block, let's just go there". Fun fact: last week I was toying with the idea to move all four stringref-related types into the 0x5_ range for the time being, "because we have that entire unused block where a stalled proposal won't get in the way of other ongoing proposals".

In short: I don't think it matters either way. 0x62, 0x67, 0x5F -- one is as good as the other.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants