working with gc types

design/mvp/Binary.md

@@ -276,6 +276,7 @@ canonopt ::= 0x00 => string-encod
  | 0x03 m:<core:memidx> => (memory m)
  | 0x04 f:<core:funcidx> => (realloc f)
  | 0x05 f:<core:funcidx> => (post-return f)
+ | 0x06 vec(<ref-options>) => (reference-type opt*) 📡
 ```
 Notes:
 * The second `0x00` byte in `canon` stands for the `func` sort and thus the

design/mvp/Explainer.md

@@ -43,6 +43,7 @@ implemented, considered stable and included in a future milestone:
 * 🪙: value imports/exports and component-level start function
 * 🪺: nested namespaces and packages in import/export names
 * 🧵: threading built-ins
+* 📡: reference types ([gc] proposal integration)
 
 (Based on the previous [scoping and layering] proposal to the WebAssembly CG,
 this repo merges and supersedes the [module-linking] and [interface-types]
@@ -591,6 +592,7 @@ sets of abstract values:
 | `own` | a unique, opaque address of a resource that will be destroyed when this value is dropped |
 | `borrow` | an opaque address of a resource that must be dropped before the current export call returns |
 
+
 How these abstract values are produced and consumed from Core WebAssembly
 values and linear memory is configured by the component via *canonical lifting
 and lowering definitions*, which are introduced [below](#canonical-definitions).
@@ -1142,6 +1144,7 @@ canonopt ::= string-encoding=utf8
  | (memory <core:memidx>)
  | (realloc <core:funcidx>)
  | (post-return <core:funcidx>)
+ | (reference-type <ref-opts>*) 📡
 ```
 While the production `externdesc` accepts any `sort`, the validation rules
 for `canon lift` would only allow the `func` sort. In the future, other sorts
@@ -1173,6 +1176,34 @@ The Canonical ABI will use `realloc` both to allocate (passing `0` for the
 first two parameters) and reallocate. If the Canonical ABI needs `realloc`,
 validation requires this option to be present (there is no default).
 
+📡 `(reference-type ...)` requires Canonical ABI to pass parameters and 
+results by reference type, which is not used by default. This option is the 
+same as (memory ...) and `(realloc ...) ` cannot be used at the same time. 
+In the MVP version, the reference type refers to the specific monomorphic 
+type, such as `(ref array (mut u8))` or `(ref $definded)` where 
+`(type $definded (struct (mut f32) (mut f32)))`, instead of type-erased 
+`(ref eq)`. In the MVP version, no mutability constraints are included, 
+and all fields are of mutable type.
+
+📡 When `reference-type` is enabled, the parameter type will change as follows:
+
+| wit type | wasm w/o `reference-type` | wasm w/ `reference-type` |
+| :------------------- | :-------------------------- | :------------------------------- |
+| `bool` | `(i32,)` | `(i32,)` |
+| `char` | `(i32,)` | `(i32,)` |
+| `u8` | `(i32,)` | `(i32,)` |
+| `u16` | `(i32,)` | `(i32,)` |
+| `u32` | `(i32,)` | `(i32,)` |
+| `u64` | `(i32,)` | `(i32,)` |
+| `resource` | `(ptr: i32)` | `(ref extern,)` |
+| `list<T>` | `(ptr: i32, len: i32)` | `(ref array (mut $t),)` |
+| `record { a, b }` | `(a: A, b: B)` (flatten) | `(ref struct $record,)` |
+| `tuple<A, B>`(in⩽16) | `(a: A, b: B)` (flatten) | `(a: A, b: B)` (flatten) |
+| `tuple<A, B>`(out>1) | `(ptr: i32)` | `(ref struct (mut $a)(mut $b),)` |
+| `option<T>` | `(i32, i32)` | `(ref null $t,)` |
+| `result<A, B>` | `(i32, i32)` | `(i32, (ref eq))` |
+| `variant` | `(i32, [MAX_VARIANT_SIZE])` | `(i32, (ref eq))` |
+
 The `(post-return ...)` option may only be present in `canon lift`
 and specifies a core function to be called with the original return values
 after they have finished being read, allowing memory to be deallocated and

design/mvp/FutureFeatures.md

@@ -38,6 +38,15 @@ to and from the statically-compiled host implementation language). See
 [`list.lift_canon` and `list.lower_canon`] for more details.
 
 
+## Mutability constraints on reference types 📡
+
+Mutability constraints are a complex issue, especially in oop languages. For 
+example, whether array is internally mutable determines whether some operations 
+can accept specific subtypes. There are no constraints in the current MVP 
+version, which may lead to unexpected semantic damage. This can only be 
+guaranteed by the language compiler for the time being, and it is not 
+cross-language safe.
+
 ## Shared-some-things linking via "adapter modules"
 
 The original [Interface Types proposal] and the re-layered [Module Linking