-
Notifications
You must be signed in to change notification settings - Fork 2
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
Stringref should probably be a subtype of anyref #40
Comments
I may misunderstand what exact property you mean. But the spec does in no way guarantee (or intend to guarantee) that every value under anyref can be classified. For starters, you can't recognise host references. There is nothing fundamentally wrong with introducing Wasm references that you cannot classify dynamically either, yet they are anyref. In fact, that's highly preferable to introducing additional top types, because each of those would form its own hierarchy and would have to come with a new bottom type as well. |
My imprecision stems from my ignorance :) Backing up a bit, I think you would want |
Okay, I see, that's a problem. Technically, I agree your suggestion would be a solution. But one that adds significant complexity to the type system. Can't say that I'd get excited about that. An alternative would be not to treat views as reference types but as a new, third category of value type that's neither numeric nor reference. Not sure that's simpler, though, it's probably even worse. Personally, I would rather avoid them sharing a representation. Not least because that results in an implementation-dependent cost model. But I fear that's the case for views already? |
To a degree, I think the question of implementation-dependent cost models is just a thing we have to deal with, for better or for worse. In an implementation using encoding X internally, it will be cheaper (and indeed possibly free) to obtain a view on a string's contents for encoding X than encoding Y. I think it's a fundamental aspect of this particular local maximum in the design space. I am sympathetic to the type system complexity question, of course. |
Just per J2WASM experience, stringref being subtype of anyref doesn't really help us since in our type system we cannot use This is in contrast to our modeling with J2CL where we backed things with JS types without wrappers where applicable. This was critical for our jsinterop story which was main driver for the compiler. This resulted in having trampolines on these top level methods to handle various mapped JS builtins however that is unlikely something we can adapt in the J2WASM case. |
Some experimentation with V8 shows that in the current implementation, stringview types are their own top types rather than being subtypes of For the time being I've changed Binaryen's implementation to match this (WebAssembly/binaryen#6440), but if this proposal ever gets revived, it would be good to properly separate the stringviews from the The current V8 implementation also disallows casts to stringview types, but this is inconsistent with the final WasmGC spec, where any reference type can be the target of a cast. It would be better to be consistent and allow casts to stringview types; if they're properly separated into their own type hierarchies, they would still be implementable as unmodified |
I'm discovering now that it seems there is no way to store a We indeed have a universal representation of types. Unlike what was said about J2WASM above, in Scala-to-Wasm we do not compromise on our JS interop story, even when compiling to Wasm. That means our universal representation must be able to store values in a way that, when crossing the JS embedding, map to the corresponding JS types. The (We are not yet attempting to use the |
@sjrd, in case you didn't know, this proposal is essentially on hold in favor of JS string builtins, so you should focus on that proposal instead. |
Oh thanks for the info. I'm also following the JS string builtins proposal, but I didn't know that it was likely to supersede |
FWIW the workaround for stringref <-> anyref, such as it is, is to allocate a |
That would not work for us, because when that That's why, for example, we do not wrap our function boxDouble(x) {
return x;
} that we import in Wasm as a |
The current V8 implementation assumes that |
Right, but not the |
For languages with a universal value representation, it would be nice to be able to have a list of "any", then pull out the individual values and do some type dispatch on those values. Strings are a fundamental kind of value, so they should support this idiom. The whole type hierarchy is in flux over at the GC proposal but at the minimum we should support the
ref.as_string
,br_on_string
,ref.is_string
set of instructions, in whatever form those instructions end up landing (WebAssembly/gc#274).On the other hand we really really want to avoid having to do this for
stringview_wtf8
,stringview_wtf16
, andstringview_iter
. We expect that on a run-time implementation that represents strings as WTF-8, that astringview_wtf8
will just be the string itself, and likewise for WTF-16 systems andstringview_wtf16
. You wouldn't be able to dynamically dispatch on the view to know its type, because stringref shares a representation. Not sure exactly how to make this happen on the spec level but the current spec has this property right now and we should preserve it :)Related to #3.
The text was updated successfully, but these errors were encountered: