Open alexcrichton opened 4 years ago
One thing I think may also need an update is the wasm_table_*
APIs. They currently operate on a wasm_ref_t
but this means that there needs to be a uniform representation, at the C API level, for reference types. Given that the reference types proposal has externref
and funcref
as separate types this may not be the best API any more?
One possible solution would be switching wasm_table_*
APIs to working with a wasm_val_t
similar to how wasm works as well. That should centralize the issue at least about how to represent these.
See also #148
One possible solution would be switching
wasm_table_*
APIs to working with awasm_val_t
similar to how wasm works as well. That should centralize the issue at least about how to represent these.
I think this would be best, since wasm_val_t
has to have the type tag anyways.
(or if types like
wasm_module_t
should be convert-ible to references)
I am also in favor of removing the everything-can-implicitly-be-a-reference stuff. If we have APIs for creating/manipulating externref
s directly, then we don't need this stuff in the spec, and can just let embedders do wasm_externref_new(my_module)
themselves or whatever.
Yeah, this is one of the issues I mentioned when we discussed the changes to references. To be honest, I still don't know how to address that properly.
Conflating the types for references and values would be a very bad idea IMO. They are different categories, and moving forward there will be more places that are specific to references. So if going the union route, than a more appropriate solution is to introduce a new union for references (and maybe hack it so that it can be treated as a subtype of value?).
However, another problem with the union approach is that I don't know how to make it scale and how to make it future-proof. It assumes a fixed partitioning into disjoint kinds of refs, but what if that changes as the language evolves, e.g., some of these become subcategories of another, or some overlap?
There's been a few changes to the reference types proposal which I don't believe have been reflected into the C API. Notably I think a few things need to be added to fully support the reference types proposal:
wasm_val_t
should be extended with awasm_func_t
orwasm_funcref_t
variant in its unionexternref
value should be supported, either through construction ofwasm_ref_t
directly or through a new typewasm_externref_t
.wasm_ref_t
and other types should still be supported (or if types likewasm_module_t
should be convert-ible to references)