-
Notifications
You must be signed in to change notification settings - Fork 70
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
Rename extern.internalize/extern.externalize? #432
Comments
I would be fine with this. |
Isn't the plan of record not to allow exnrefs to be passed to JavaScript? Then such a conversion wouldn't be very useful. That said, I don't mind a more extensible naming scheme. Instead of |
Hmm, my understanding was that this wasn't well discussed yet. It's fine if we disallow it, but I do think there is a good case for allowing it (and will make that on the EH issue).
Yeah, that's fine with me. Even if we don't immediately allow this for exnref, I do think this is something that is likely to come up in some future extension. |
I think the next step is to make a PR implementing this change. @rossberg, would you be up for that? |
Sure, though I might not get to it for the next couple of weeks. |
Rename instructions `extern.internalize` into `any.convert_extern` and `extern.externalize` into `extern.convert_any` to follow more closely the spec. This was changed in WebAssembly/gc#432. The legacy name is still accepted in text inputs and in the C and JS APIs.
In discussions around adding an 'exnref' type (WebAssembly/exception-handling#280), it seemed like there was desire for it to be a new type hierarchy, like any and extern. If this is the case, it could be useful to have instructions to convert from 'exnref' to 'externref' or 'anyref'. This has sort of come up before (WebAssembly/exception-handling#202).
I can't think of a good name for these though, as 'extern.internalize/externalize' seem to have a builtin assumption that you just want to convert between those two hierarchies.
What would folks think about renaming to:
any.from_extern
andextern.from_any
? This would allow a naturalany.from_exn
orextern.from_exn
?The text was updated successfully, but these errors were encountered: