Can continuation references flow to JS?

[tlively]

Most types can be passed to JS. The only current exceptions are v128 and exn references. At time of writing, the explainer does not say one way or the other.

[fgmccabe]

There does not seem to be a lot of merit in allowing this. The only thing that JS would be allowed to do is to pass it back to wasm.

[tlively]

Yes, but that's all you can do with struct and array references today, and it's still useful. Being able to pass around opaque references is sufficient to allow JS to use and access the references by passing them to Wasm exports. I would expect that allowing new kinds of references to flow to JS would be the default position, so I would turn the question around and ask what is the merit of disallowing it?

I guess this interacts with the casting question in #115 because it would be impossible to pass a continuation reference back into WebAssembly with a specific type unless it had runtime type information available.

[eqrion]

It looks like cont is a top type like funcref, and doesn't have identity. If we let JavaScript hold a reference to it we would need to figure out the behavior of ===. For funcref the JS engines actually maintain identity for funcrefs and just only expose it to JS.

Is there a story for how identity/equality could work for continuation references?

[tlively]

Wouldn't it just be reference equality like we have for anyrefs that flow out? As with anyrefs and funcrefs, it shouldn't matter that their identity is not directly observable from inside Wasm. In the JS spec we would associate JS objects with continuation addresses from the Wasm store.

[rossberg]

Under an allocaition-free fat pointer representation, reference equality for continuations would have to compare the entire fat pointer. Since that would presumably have to be boxed up for JS in most engines, passing out a cont while maintaining the correct identity would then involve allocation with memoization, which complicates the memory management story for continuations.

All doable in principle, but I don't see the value of this extra complexity, before we even start considering the runtime type problem. If you ever need to roundtrip a cont through JS, you can always store it in a struct explicitly. JS cannot do anything interesting with it anyway.

[tlively]

We talked about this in the stacks subgroup today and we decided to disallow continuation references from flowing to JS. This is the conservative option and avoids bad interactions with the decision to disallow continuation casts in #115.

Leaving the issue open because the explainer and JS specs need to be updated accordingly.