Andreas Rossberg

It's also not possible to emulate `return_call` in core Wasm. Perhaps the person asking was missing that tail calls are more general than just tail recursion?

There are only non-local transformations, and they are either very expensive (trampolining through exception handlers, like @fgmccabe is alluding to, provided you even have them) or only practical in simple...

What @tlively says. In general, the type system is designed such that reachability has the least possible interaction with other typing rules. There are no special cases for unreachable code...

A while ago I heard about the intent to include 64-bit tables as well, in order to be able to compile function pointers consistently. What became of that?

Yeah, from my perspective, Wasm64 is incomplete without it, and it leaves the language in an odd space. Do you think it would still be realistic to extend the proposal?

@bvisness, I'd think so.

Yes, spec/interpreter/test-side all boxes have been checked 4 years ago, just waiting for implementations to catch up. :) Happy to see progress on this!

What @dschuff said, the JS API shouldn't need anything to support this, as nothing in it depends on the fact that only a single memory can currently occur in import...

> For imports, the memory object is created outside of Wasm, and the index itself isn't meaningful, but can be queried from the memory object itself. Hm, did you mean...

There is no implicit conversion for function references, you'll have to use WebAssembly.Function. That is the only way I am aware to reliably provide the necessary Wasm type information to...