You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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?
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.
Originally posted by @sjrd in #18 (comment)
The text was updated successfully, but these errors were encountered: