dcodeIO

> But I expect that the larger Wasm community cares a lot about non-Java-like languages and non-browser Wasm engine It seems this aspect is somewhat similar to the larger Wasm...

Indeed, having a functioning string type for interop with JavaScript is what I need specifically, but I am equally interested in designing Wasm in a consistent way for many languages...

Seems brittle if construction and runtime don't match up. For example, I wonder what tools like Wizer and Binaryen would do when they precompute string data and aren't able to...

In general I have the impression that being able to tell, from an operation, whether an access was performed out of bounds would provide maximum utility and perhaps even aid...

> Yup. 100%. WAI needs to be completely agnostic between languages. We started from Interface Types because it was way easier for us to start with. But WAI aims towards...

Right, this gives us the four cases | Source string | Destination string | Description |----------------|---------------------|--------------- | `DOMString` | `DOMString` | All good | `USVString` | `USVString` | All good...

Alternatively, say we'd build upon Interface Types in a minimum way while also striving to make it compatible with the current state of `stringref`, a potential set of changes could...

Spec-wise, when using a single `string` type (defined as the common denominator "list of code points except surrogate code point pairs"), we'd end up with one set of `string-encoding`s where...

Just in case it's useful: If necessary, could also emulate what `externref` + a table would natively provide by maintaining a custom `index => ptr` mapping on the host side...

Type-wise the compiler currently assumes that `var a: SomeEnum` is `i32`. As such, mixing different kinds of values appears problematic in about the same way union types are. Pure string...