-
Notifications
You must be signed in to change notification settings - Fork 764
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
Wasm vs Wasm2js export naming is incompatible #2310
Comments
I don't know much about the second option - how would that work? Something like the exports would be named by strings, instead of JS vars? That sounds good in general to me, I didn't know that it was possible to use string names for all the imports and exports that we need here. |
To me it seems that ES module exports, which must be valid JS identifiers, and Wasm module exports, which allow additional characters, is generally incompatible, instead requiring exporting some sort of object that one can set arbitrary properties on. That is, if I'm not missing something. I also wonder how this is supposed to interop with JS in the first place, since if the module has a |
I'm not sure.. @alexcrichton I think you made the change to ES6 module output here, perhaps you had a plan for this stuff? |
I didn't personally consider this use case when originally porting wasm2js, but I'd recommend following whatever the ES integration spec for wasm says in this regard. It might be more reasonable for wasm2js to generate an error rather than apply its own mangling scheme, but otherwise I'm not sure how wasm2js would handle this. |
With Wasm2js generating valid ES modules, some information about export names is lost making Wasm modules and their Wasm2js counterpart non-interchangeable.
For example, if the Wasm module exports a function named
hello#world
, this will be exported as-is in Wasm but ashello_world
in Wasm2js output.Now one could argue that the mangling is necessary to make ES modules in the first place, and another person could argue that compatibility of the resulting module instance is more important. I'd personally favor the latter, since AssemblyScript uses export names (which do allow such symbols by the spec) to transport information about what is an instance method as part of the export's name (like
MyClass#myInstanceMethod
vsMyClass.myStaticMethod
).Any thoughts?
The text was updated successfully, but these errors were encountered: