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,11 +1144,14 @@ 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
 may be added (viz., types), hence the explicit sort.
 
+##### `string-encoding` options
+
 The `string-encoding` option specifies the encoding the Canonical ABI will use
 for the `string` type. The `latin1+utf16` encoding captures a common string
 encoding across Java, JavaScript and .NET VMs and allows a dynamic choice
@@ -1156,6 +1161,8 @@ Point range) or UTF-16 (which can express all Code Points, but uses either
 default is UTF-8. It is a validation error to include more than one
 `string-encoding` option.
 
+##### `memory` options
+
 The `(memory ...)` option specifies the memory that the Canonical ABI will
 use to load and store values. If the Canonical ABI needs to load or store,
 validation requires this option to be present (there is no default).
@@ -1173,6 +1180,49 @@ 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` options
+
+📡 `(reference-type ...)` does not take effect by default. When this option 
+is turned on, Canonical ABI will be required to use reference types to pass 
+parameters. This option conflicts with `memory` and `realloc` and cannot 
+exist at the same time.
+
+📡 In the MVP version, the reference type refers to the specific monomorphic 
+type, such as `(ref array (mut u8))`, instead of type-erased 
+`(ref eq)`. 
+
+📡 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),)` |
+| `result<A, B>`       | `(i32, i32)`                | `(i32, (ref eq))`                 |
+| `variant`            | `(i32, [MAX_VARIANT_SIZE])` | `(i32, (ref eq))`                 |
+
+📡 Nullable types are treated specially in many languages and are therefore not 
+considered variants when the `reference-types` option is on.
+
+| wit type               | wasm w/o `reference-type` | wasm w/ `reference-type` |
+|:-----------------------|:--------------------------|:-------------------------|
+| `option<bool>`         | `(i32, i32)`              | `(ref null i31)`         |
+| `option<char>`         | `(i32, i32)`              | `(ref null i32)`         |
+| `option<i8>`           | `(i32, i32)`              | `(ref null i31)`         |
+| `option<i32>`          | `(i32, i32)`              | `(ref null i32)`         |
+| `option<i64>`          | `(i32, i64)`              | `(ref null i64)`         |
+| `option<T>` (ref type) | `(i32, SIZE_OF_T)`        | `(ref null $t)`          |
+
+##### `post-return` options
+
 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,23 @@ 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.
+
+## Integrate `stringref` with reference types 📡
+
+The current wit `string` type is regarded as `(array (u8))` or `(array (mut u8))`. 
+When the `stringref` proposal is stable, it can be considered to be mapped to 
+`stringref`. In other words, the `reference-type` option can work together with 
+the `string-encoding` option.
+
+
 ## Shared-some-things linking via "adapter modules"
 
 The original [Interface Types proposal] and the re-layered [Module Linking