Andreas Rossberg

Hm, is this addressing a real problem? A module that's gonna be distributed to workers won't typically be compiled as an ESM module I think, since you won't need an...

If convenience with ESMs is the only motivation then it might be more adequate and more lightweight to just add respective functionality at the ESM integration level. For example, the...

> The ability to instantiate type parameters with type arguments means new types are constructed during type checking and consequently have no entries in a memoization table. I would assume...

It seems like there is general agreement to refactor the opcodes along these lines. I'll try to come up with a coherent design. The main question will be when to...

> With this mantra in mind, we should at least make sure that the consolidated instructions behave identically apart from the tested type. Absolutely. Currently, there are three different flavours:...

@jakobkummerow, is the point that `is_data` actually is more precise (and expensive) than what would be needed to ensure you can extract an RTT from an anyref that is not...

@jakobkummerow, got it, thanks for the clarification.

@askeksa-google, thanks, that's roughly what I had in mind, except that I'd restrict the heaptype to be abstract and keep the instructions involving concrete types and RTTs separate like the...

@tlively, as hinted at in the OP, I had in mind s.th more moderate, like (picking up @askeksa-google's idea for two versions of ref.as): * `ref.is : [anyref] -> [i32]`...

@askeksa-google: > How does `func_or_data` fit into our current hierarchy? It seems incompatible with `eq`, since neither is a subtype of the other, and both are supertypes of `data`. Subtyping...