-
-
Notifications
You must be signed in to change notification settings - Fork 676
Implement stringref operations #2687
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
Conversation
With #2689 in place, instructions that technically accept but would throw when provided a stringref
that is null
now take ref_string
(non-nullable stringref
), effectively eliminating the possibility of such traps statically per the type system. Similarly, instructions that cannot produce null
use ref_string
as their return type, with tests showing that V8 materializes a non-nullable type there as well, i.e. respective assignments succeeding. One exception is string.eq
, as it can deal with null
inputs.
There is some proof of concept code now, showing how RefString
can be populated with functionality utilizing the stringref instruction set. Basically, in a ref_string
type context, a string literal compiles to a string.const
, making a reference-typed string. Such a value of type ref_string
is backed by the RefString
wrapper class (in std/assembly/references.ts) providing the JS-like API that mostly vanishes after optimizations, leaving primarily the string instructions. So the underlying Wasm type in AS is simply (ref string)
that can be exchanged with JS and Web APIs by reference.
Quick update: There has been a more general string discussion in CG context meanwhile. Iiuc, an alternative to stringref
that instead uses (non-portable?) compile time imports for common string operations has been discussed. Also noteworthy:
The Wasmtime project would prefer not to implement
stringref
. We don't have a managed host string to expose to Wasm guests, and we don't want to have to implement one. We would rather that Wasm guests implement their own strings on top of the GC proposal, where they can build exactly what they need, which can be very different across languages. As far as interoperability of strings across different languages goes, we believe this should be addressed at the component model and interface types layer. For tight integration with JS strings on the Web, string imports seem like a good solution.
Translated: Our thing that intentionally does not address the thing should be off-label responsible for the thing so we can not address the thing and eventually the Web becomes the special case - it's (削除) Business (削除ここまで)Wasmtime!
This PR has been automatically marked as stale because it has not had recent activity. It will be closed in one week if no further activity occurs. Thank you for your contributions!
This PR has been automatically closed due to lack of recent activity, but feel free to reopen it as long as you merge in the main branch afterwards.
This PR has been automatically marked as stale because it has not had recent activity. It will be closed in one week if no further activity occurs. Thank you for your contributions!
This PR has been automatically closed due to lack of recent activity, but feel free to reopen it as long as you merge in the main branch afterwards.
Uh oh!
There was an error while loading. Please reload this page.
Implements the current state of the Reference-Typed Strings proposal (currently phase 1) as supported by Binaryen, for now as built-ins to enable experimentation. A constant reference-typed string can be created using a string literal in a
ref_string
context.Enable with
--enable stringref
in AS,--experimental-wasm-stringref
in V8.✔️ Available ⏳ Available but incomplete ❌ Not available
Possible follow-up work in case there is interest: Populate the
RefString
wrapper class using the instructions to mimicString
, so it can eventually replaceString
. So far this PR implements a few string functions as a POC.