Working with wit component

[oovm]

I'm hoping to use wasm-gc with wit-component, and since neither project is finally stable, I wanted to do some
preliminary discussions.

When enabling the gc type, a gc related option should be added to specify the abi type. resource, list, record all
have corresponding reference types.

But I don’t know how to deal with the rest better, especially variant. Many gc languages do not have this concept.
Conceptually, the closest role is similar to an abstract class.

wit	wasm w/o gc	wasm w/gc
bool	(i32,)	(i32,)
char	(i32,)	(i32,)
u8	(i32,)	(i32,)
u16	(i32,)	(i32,)
u32	(i32,)	(i32,)
u64	(i32,)	(i32,)
resource	(ptr: i32)	(extern.ref)
list<A>	(ptr: i32, len: i32)	(array.ref)
record { a, b }	(a: A, b: B)	(struct.ref)
tuple<A, B>	(a: A, b: B)	?
option<A>	(i32, i32)	?
result<A, B>	(i32, i32)	?
variant	(i32, [MAX_VARIANT])	?

This is a cross-domain and does not belong to the Post-MVP of wasm-gc, and subsequent rule updates should occur on the
wit-component side.

[rossberg]

A while ago, I gave a presentation about two prototype compilers I wrote (one for an object-oriented, one for a functional language) and how they make use of GC types, both for boxed and unboxed representations:

https://github.com/WebAssembly/meetings/blob/main/gc/2021/presentations/2021-10-19%2B-rossberg-wob.pdf

In particular, this also discusses tuples, variants, objects, generics (options and results are just cases of variants).

The short answer is that a tuple is no different from a record, and a variant is an eq ref that is either an i31 ref (for cases without arguments) or a struct whose first field is an i32 and the rest are its arguments.

PS: The GC proposal is final at this point.

[oovm]

Thank you very much for your information, I improved part of the implementation based on wob.

I have another question, I want to know how the trait should be implemented?

For example, implement IReset { reset() } for C, D <: C.

Should the $i-reset-vt virtual table pointer be added to $C, which contains a reset(ptr: (eqref $C)) function pointer?

[rossberg]

Interfaces/traits or other forms of multiple inheritance are more difficult, and do not directly map to simple Wasm constructs. In general, you'll have to do what a native-code backend does, but the details depend on the specific semantics of your traits, so there is no generic answer. However, there are various optimisation tricks in this area, and not all of them are likely portable to Wasm GC. And the implementation will certainly need Wasm-level casts quite a bit.

Perhaps you can get some inspiration from the J2CL Wasm GC port for Java or Kotlin's Wasm GC implementation.

[oovm]

Okay, thank you for your answer, I have no more doubts