Should rust have a new target triple for wasm builtins?
Until now wasm targets have not been able to have any assumption of runtime host, that’s why wasm32-unknown-unknown target exists which does not make any assumption of surrounding host.
Now there are builtins, first the JS String Builtins, and soon Primitive builtins and after that who knows what. Suddenly the rust compiler could make assumptions that there are some functions imported from host environment.
Should there be new target triple, something like wasm32-unknown-builtins or similar, which is for environments which have all standard builtins exposed to the wasm executable?
Is this specific to web targets of wasm? It seems strange that wasm for web doesn't have a separate triplet than wasm for embedded scripts in applications already. There are separate targets for WASI after all.
I think it is more likely that wasm-bindgen would be the one responsible for using those things, which can use the wasm32-unknown-unknown target just fine. Rustc would only use those things if rust were to get builtin language support for these things, which doesn't seem necessary when extern crates can handle that just fine.
Seems specific to WASM+JS targets, such as web, Node.js, and Deno. they don't necessarily include all the web APIs (e.g. Node.js doesn't have HTMLIFrameElement but does have JavaScript strings) so I don't think we should have it be the web target, though having a separate web target for when you actually need access to the DOM could be useful.
The most pressing use-case here is for languages who would like to use the JavaScript String type to implement their strings.
However, Rust can't do that. JS strings are UTF-16-ish (or we could call, WTF-16), while Rust strings are UTF-8. So Rust strings must remain a separate data type.
Maybe Javascript strings could be exposed by the stdlib on std::ffi on wasm targets that have strings builtins though (as a separate type: Rust stdlib already have str/String, CStr/CString, OsStr/OsString, and now would have a fourth string type JsStr/JsString available just on this specific target). Or at least some facility to create Javascript string literals.
Or maybe, even, OsStr / OsString could be repurposed as a Javascript string on wasm targets with string builtins. The docs already say that sometimes, OsString is WTF-16. This may or may not be a good idea, but it seems doable.
Note, OsString and OsStr internally do not necessarily hold strings in the form native to the platform; While on Unix, strings are stored as a sequence of 8-bit values, on Windows, where strings are 16-bit value based as just discussed, strings are also actually stored as a sequence of 8-bit values, encoded in a less-strict variant of UTF-8. This is useful to understand when handling capacity and length values.
…so probably not specifically OsString being freely JS-compatible. I guess that’s not a guarantee of OsString’s representation, but if it’s not being used for UTF-16 on any existing platform, extending it to be for wasm is a lot more work. And could backfire if other wasi APIs end up wanting to speak something 8-bit-based.