From e6ab489490bdba038dc4cc9435c393a3c351d4ed Mon Sep 17 00:00:00 2001
From: Ben Visness <bvisness@mozilla.com>
Date: Mon, 17 Aug 2026 17:10:57 -0500
Subject: [PATCH 01/10] Add getters and setters to WIT and AST

---
 design/mvp/Binary.md    | 25 +++++++++++++-----
 design/mvp/Explainer.md | 57 ++++++++++++++++++++++++++---------------
 design/mvp/WIT.md       | 38 ++++++++++++++++++++-------
 3 files changed, 84 insertions(+), 36 deletions(-)

diff --git a/design/mvp/Binary.md b/design/mvp/Binary.md
index 51a7f2e7..f8c55962 100644
--- a/design/mvp/Binary.md
+++ b/design/mvp/Binary.md
@@ -420,10 +420,10 @@ Notes:
   be [strongly-unique]; attributes are ignored.
 * The `externname`s of all exports in a given component, instance, component-
   type or instance-type must be [strongly-unique]; attributes are ignored.
-* Validation requires that `[constructor]`, `[method]` and `[static]` annotated
-  `plainname`s only occur on `func` imports or exports and that the first label
-  of a `[constructor]`, `[method]` or `[static]` matches the `plainname` of a
-  preceding `resource` import or export, respectively, in the same scope
+* Validation requires that `plainname`s annotated with `[constructor]`,
+  `[method]`, `[static]`, `[get]`, or `[set]` only occur on `func` imports or
+  exports and that the first `label` of such a name matches the `plainname` of
+  a preceding `resource` import or export, respectively, in the same scope
   (component, component type or instance type).
 * 🏷️ Validation requires that `implements`-annotated imports or exports are
   `instance`-typed and have a `plainname` name.
@@ -433,10 +433,21 @@ Notes:
   `vec(<attribute>)`, this list is entirely ignored when validating the types
   of components and instances.
 * Validation of `[constructor]` names requires a `func` type whose result type
-  is either `(own $R)` or `(result (own $R) E?)` where `$R` is a resource type
-  labeled `r`.
+  is either `(own $R)` or `(result (own $R) E?)`, where `$R` is the named
+  resource type.
 * Validation of `[method]` names requires the first parameter of the function
-  to be `(param "self" (borrow $R))`, where `$R` is the resource labeled `r`.
+  to be `(param "self" (borrow $R))`, where `$R` is the named resource type.
+* Validation of `[get]` names requires that the function have a single
+  parameter `(param "self" (borrow $R))`, where `$R` is the named resource
+  type, and that the function have a return type.
+* Validation of `[set]` names requires that the function have exactly two
+  parameters, that the first parameter be `(param "self" (borrow $R))`, and
+  that the function have either no return type or `(result (error $E)?)`.
+* If both a `[get]` and `[set]` are defined with the same name (that is, if
+  they have the same `label`s), and the setter's second parameter has type
+  `$T`, then the getter's result type must be either `$T` or
+  `(result $T (error $E)?)`.
+* 🔀 Functions with `[get]` or `[set]` names must not be `async`.
 * 🔗 Validation requires that `versionsuffix` is preceded by an `interfaceversion`
   matching `canonversion` and that the concatenation of the `canonversion` and
   the `versionsuffix` results in a `valid semver` as defined by
diff --git a/design/mvp/Explainer.md b/design/mvp/Explainer.md
index 3e7f8c95..e73c41dc 100644
--- a/design/mvp/Explainer.md
+++ b/design/mvp/Explainer.md
@@ -2711,6 +2711,8 @@ plainname         ::= <label>
                     | '[constructor]' <label>
                     | '[method]' <label> '.' <label>
                     | '[static]' <label> '.' <label>
+                    | '[get]' <label> '.' <label>
+                    | '[set]' <label> '.' <label>
 labellit          ::= '"' <label> '"'
 label             ::= <first-fragment> ( '-' <fragment> )*
 first-fragment    ::= <first-word>
@@ -2746,29 +2748,32 @@ The names of component imports and exports provide two options:
 The `plainname` production captures several language-neutral syntactic hints
 that allow bindings generators to produce more idiomatic bindings in their
 target language. At the top-level, a `plainname` allows functions to be
-annotated as being a constructor, method or static function of a preceding
-resource.
-
-When a function is annotated with `constructor`, `method` or `static`, the
-first `label` is the name of the resource and the second `label` is the logical
-field name of the function. This additional nesting information allows bindings
-generators to insert the function into the nested scope of a class, abstract
-data type, object, namespace, package, module or whatever resources get bound
-to. For example, a function named `[method]C.foo` could be bound in C++ to a
-member function `foo` in a class `C`. The JS API [below](#JS-API) describes how
-the native JavaScript bindings could look.
+annotated as being a constructor, method, getter, setter or static function of
+a preceding resource.
+
+When a function is annotated with `constructor`, `method`, `static`, `get`, or
+`set`, the first `label` is the name of the resource and the second `label` is
+the logical field name of the function. This additional nesting information
+allows bindings generators to insert the function into the nested scope of a
+class, abstract data type, object, namespace, package, module or whatever
+resources get bound to. For example, a function named `[method]C.foo` could be
+bound in C++ to a member function `foo` in a class `C`. The JS API
+[below](#JS-API) describes how the native JavaScript bindings could look.
 
 To restrict the set of cases that bindings generators need to consider, these
-annotations trigger additional type-validation rules (listed in
-[Binary.md](Binary.md)) such as:
+annotations trigger additional type-validation rules (listed in detail in
+[Binary.md](Binary.md)):
 * An import or export named `[static]R.foo` must be a function and `R` must
   be the name of an imported or exported resource type in the same `instance`
   or `component` type.
-* Similarly, an import or export named `[constructor]R` must be a function
+* An import or export named `[constructor]R` must be a function
   whose return type must be `(own $R)` or `(result (own $R) (error <valtype>)?)`
   where `$R` is the type-index of the resource type named `R`.
-* Similarly, an import or export named `[method]R.foo` must be a function whose
+* An import or export named `[method]R.foo` must be a function whose
   first parameter must be `(param "self" (borrow $R))`.
+* An import or export named `[get|set]R.foo` must be a function whose first
+  parameter must be `(param "self" (borrow $R))` and which is required to have
+  a result type or second parameter respectively.
 
 The `valid semver` production is as defined by the [Semantic Versioning 2.0]
 spec and is meant to be interpreted according to that specification. The use of
@@ -2836,24 +2841,36 @@ Values]) are **strongly-unique**:
   1. Lowercase all the `acronym`s (uppercase letters) in the name.
   2. If the name is `[method]l.l` or `[static]l.l` for some `label` `l`, replace
     the name with `l` (e.g. `[method]foo.foo` becomes `foo`).
-  3. If the name has any `[...]` annotation prefix other than `[constructor]`,
-    strip it from the name.
+  3. If the name has any `[...]` annotation prefix other than `[constructor]`
+    or `[set]`, strip it from the name.
 2. The names are strongly-unique if the resulting canonicalized strings are
   unequal.
 
 Thus, the following set of names are strongly-unique and can thus all be imports (or exports) of the same component (or component type or instance type):
-* `foo`, `foo-bar`, `[constructor]foo`, `[method]foo.bar`, `[static]foo.baz`, `foo:bar/baz`
+* `foo`, `foo-bar`, `[constructor]foo`, `[method]foo.bar`, `[static]foo.baz`,
+  `foo:bar/baz`, `[get]foo.prop`, `[set]foo.prop`, `[method]foo.get-prop`,
+  `[method]foo.set-prop`
 
 but attempting to add *any* of the following names would be a validation error:
-* `foo`, `FOO`, `foo-BAR`, `[constructor]FOO`, `[method]foo.BAR`, `[static]foo.bar`, `[method]foo.baz`, `[method]foo.foo`, `[static]foo-BAR.FOO-bar`, `foo:bar/BAZ`
+* `foo`, `foo-BAR`, `[constructor]foo-BAR`, `[method]foo.foo`,
+  `[method]foo.BAR`, `foo:bar/baz`, `[method]foo.prop`, `[static]foo.PROP`,
+  `[get]foo.PROP`, `[set]foo.PROP`
 
-The purpose of steps 1.2 and 1.3 is to play nice with constructors: in many languages, constructors are the only item that can have the same name as the class.
+The purpose of step 1.2 and the `[constructor]` provision of step 1.3 is to
+play nice with constructors: in many languages, a constructor is the only item
+that can have the same name as the class.
 
 Note that additional validation rules involving types apply to names with
 annotations. For example, the validation rules for `[constructor]foo` require
 `foo` to be a resource type. See [Binary.md](Binary.md#import-and-export-definitions)
 for details.
 
+Note also that `[get]foo.prop` and `[method]foo.get-prop` are considered
+strongly-unique even though in practice they may conflict. If this results in
+a conflict for a bindings generator, the bindings generator may just pick one
+of the two. This is a temporary measure that is expected to be restricted for a
+1.0 release.
+
 
 #### 🔗 Canonical Interface Name
 
diff --git a/design/mvp/WIT.md b/design/mvp/WIT.md
index f7c58af7..5954112e 100644
--- a/design/mvp/WIT.md
+++ b/design/mvp/WIT.md
@@ -1069,6 +1069,7 @@ keyword ::= 'as'
           | 'from'
           | 'func'
           | 'future'
+          | 'get'
           | 'import'
           | 'include'
           | 'interface'
@@ -1084,6 +1085,7 @@ keyword ::= 'as'
           | 's32'
           | 's64'
           | 's8'
+          | 'set'
           | 'static'
           | 'stream'
           | 'string'
@@ -1765,15 +1767,26 @@ transform: func(blob) -> blob;
 
 As syntactic sugar, resource statements can also declare any number of
 *methods*, which are functions that implicitly take a `self` parameter that is
-a handle. A resource statement can also contain any number of *static
-functions*, which do not have an implicit `self` parameter but are meant to be
-lexically nested in the scope of the resource type. Lastly, a resource
-statement can contain at most one *constructor* function, which is syntactic
-sugar for a function returning a handle of the containing resource type.
+a handle. A resource statement can also contain any number of *getters* and
+*setters*, which also implicitly take a `self` parameter and have additional
+validation restrictions on their result and parameter types. A resource
+statement can also contain any number of *static functions*, which do not have
+an implicit `self` parameter but are meant to be lexically nested in the scope
+of the resource type. Lastly, a resource statement can contain at most one
+*constructor* function, which is syntactic sugar for a function returning a
+handle of the containing resource type.
+
 Constructors can be fallible or infallible. Fallible constructors have an
-explicitly-written return type which must be of the form `result<r, ...>`
-where `r` is the name of the containing `resource`. Infallible constructors
-have no written return type and are given the implicit return type `r`.
+explicitly-written return type which must be of the form `result<r, ...>` where
+`r` is the name of the containing `resource`. Infallible constructors have no
+written return type and are given the implicit return type `r`.
+
+Getters take no parameters (besides the implicit `self` parameter) and must
+return a value. Setters take exactly one parameter (besides the implicit `self`
+parameter) and may not return a value unless that value is of type
+`result<_, error?>`. If a getter and setter are defined with the same name, and
+the setter's value type is `t`, then the getter's return type must be either
+`t` or `result<t, error?>`.
 
 For example, the following resource definition:
 ```wit
@@ -1782,6 +1795,8 @@ resource blob {
     write: func(bytes: list<u8>);
     read: func(n: u32) -> list<u8>;
     merge: static func(lhs: borrow<blob>, rhs: borrow<blob>) -> blob;
+    position: get() -> u64;
+    position: set(value: u64);
 }
 resource blob2 {
     constructor(init: list<u8>) -> result<blob2>;
@@ -1795,6 +1810,8 @@ resource blob;
 %[method]blob.write: func(self: borrow<blob>, bytes: list<u8>);
 %[method]blob.read: func(self: borrow<blob>, n: u32) -> list<u8>;
 %[static]blob.merge: func(lhs: borrow<blob>, rhs: borrow<blob>) -> blob;
+%[get]blob.position: func(self: borrow<blob>) -> u64;
+%[set]blob.position: func(self: borrow<blob>, value: u64);
 ```
 These `%`-prefixed strings embed the resource type name so that bindings
 generators can generate idiomatic syntax for the target language or (for
@@ -1814,6 +1831,8 @@ resource-item ::= 'resource' id ';'
                 | 'resource' id '{' ( gate external-id? resource-method )* '}'
 resource-method ::= func-item
                   | id ':' 'static' func-type ';'
+                  | id ':' 'get' param-list result-list ';'
+                  | id ':' 'set' param-list result-list ';'
                   | 'constructor' param-list ';'
 ```
 
@@ -1960,7 +1979,8 @@ is expanded into:
 resource file
 %[method]file.read: func(self: borrow<file>, n: u32) -> list<u8>;
 ```
-where `%[method]file.read` is the desugared name of a method.
+where `%[method]file.read` is the desugared name of a method. The same applies
+to the getter and setter syntax.
 
 
 ## Name resolution

From 9639973845b376415eac56553675d51d7e2c37c5 Mon Sep 17 00:00:00 2001
From: Ben Visness <bvisness@mozilla.com>
Date: Wed, 19 Aug 2026 10:54:02 -0500
Subject: [PATCH 02/10] Make [*]l.l more general again; improve examples

---
 design/mvp/Explainer.md | 17 +++++++++--------
 1 file changed, 9 insertions(+), 8 deletions(-)

diff --git a/design/mvp/Explainer.md b/design/mvp/Explainer.md
index e73c41dc..7318f96e 100644
--- a/design/mvp/Explainer.md
+++ b/design/mvp/Explainer.md
@@ -2838,11 +2838,11 @@ within the same scope.
 To determine whether two names (defined as sequences of [Unicode Scalar
 Values]) are **strongly-unique**:
 1. Canonicalize each name:
-  1. Lowercase all the `acronym`s (uppercase letters) in the name.
-  2. If the name is `[method]l.l` or `[static]l.l` for some `label` `l`, replace
-    the name with `l` (e.g. `[method]foo.foo` becomes `foo`).
-  3. If the name has any `[...]` annotation prefix other than `[constructor]`
-    or `[set]`, strip it from the name.
+    1. Lowercase all the `acronym`s (uppercase letters) in the name.
+    2. If the name is `[*]l.l` for any annotation [*] and some `label` `l`,
+        replace the name with `l` (e.g. `[method]foo.foo` becomes `foo`).
+    3. If the name has any `[...]` annotation prefix other than `[constructor]`
+        or `[set]`, strip it from the name.
 2. The names are strongly-unique if the resulting canonicalized strings are
   unequal.
 
@@ -2852,9 +2852,10 @@ Thus, the following set of names are strongly-unique and can thus all be imports
   `[method]foo.set-prop`
 
 but attempting to add *any* of the following names would be a validation error:
-* `foo`, `foo-BAR`, `[constructor]foo-BAR`, `[method]foo.foo`,
-  `[method]foo.BAR`, `foo:bar/baz`, `[method]foo.prop`, `[static]foo.PROP`,
-  `[get]foo.PROP`, `[set]foo.PROP`
+* `foo`, `FOO`, `foo-BAR`, `[constructor]FOO`, `[method]foo.BAR`,
+  `[static]foo.bar`, `[method]foo.baz`, `[method]foo.foo`,
+  `[static]foo-BAR.FOO-bar`, `[get]foo.foo`, `foo:bar/BAZ`, `[method]foo.prop`,
+  `[static]foo.PROP`, `[get]foo.PROP`, `[set]foo.PROP`
 
 The purpose of step 1.2 and the `[constructor]` provision of step 1.3 is to
 play nice with constructors: in many languages, a constructor is the only item

From f2aa864f08ea27d93390d211886ccf90c2a81b10 Mon Sep 17 00:00:00 2001
From: Ben Visness <bvisness@mozilla.com>
Date: Wed, 19 Aug 2026 13:02:57 -0500
Subject: [PATCH 03/10] Emoji-gate getters and setters

---
 design/mvp/Binary.md    | 20 +++++++------
 design/mvp/Explainer.md | 63 ++++++++++++++++++++++++-----------------
 design/mvp/WIT.md       | 35 +++++++++++------------
 3 files changed, 65 insertions(+), 53 deletions(-)

diff --git a/design/mvp/Binary.md b/design/mvp/Binary.md
index f8c55962..9821aece 100644
--- a/design/mvp/Binary.md
+++ b/design/mvp/Binary.md
@@ -421,9 +421,9 @@ Notes:
 * The `externname`s of all exports in a given component, instance, component-
   type or instance-type must be [strongly-unique]; attributes are ignored.
 * Validation requires that `plainname`s annotated with `[constructor]`,
-  `[method]`, `[static]`, `[get]`, or `[set]` only occur on `func` imports or
-  exports and that the first `label` of such a name matches the `plainname` of
-  a preceding `resource` import or export, respectively, in the same scope
+  `[method]`, `[static]`, 📡 `[get]`, or 📡 `[set]` only occur on `func` imports
+  or exports and that the first `label` of such a name matches the `plainname`
+  of a preceding `resource` import or export, respectively, in the same scope
   (component, component type or instance type).
 * 🏷️ Validation requires that `implements`-annotated imports or exports are
   `instance`-typed and have a `plainname` name.
@@ -437,17 +437,19 @@ Notes:
   resource type.
 * Validation of `[method]` names requires the first parameter of the function
   to be `(param "self" (borrow $R))`, where `$R` is the named resource type.
-* Validation of `[get]` names requires that the function have a single
+* 📡 Validation of `[get]` names requires that the function have a single
   parameter `(param "self" (borrow $R))`, where `$R` is the named resource
   type, and that the function have a return type.
-* Validation of `[set]` names requires that the function have exactly two
+* 📡 Validation of `[set]` names requires that the function have exactly two
   parameters, that the first parameter be `(param "self" (borrow $R))`, and
   that the function have either no return type or `(result (error $E)?)`.
-* If both a `[get]` and `[set]` are defined with the same name (that is, if
-  they have the same `label`s), and the setter's second parameter has type
-  `$T`, then the getter's result type must be either `$T` or
+* 📡 If `[set]a.b` is defined within a particular scope, then `[get]a.b` must
+  have already been defined in that same scope. (That is, the `label`s must be
+  equal, and the getter must precede the setter.)
+* 📡 If a `[set]` function's second parameter has type `$T`, then its
+  corresponding `[get]` function's result type must be either `$T` or
   `(result $T (error $E)?)`.
-* 🔀 Functions with `[get]` or `[set]` names must not be `async`.
+* 🔀/📡 Functions with `[get]` or `[set]` names must not be `async`.
 * 🔗 Validation requires that `versionsuffix` is preceded by an `interfaceversion`
   matching `canonversion` and that the concatenation of the `canonversion` and
   the `versionsuffix` results in a `valid semver` as defined by
diff --git a/design/mvp/Explainer.md b/design/mvp/Explainer.md
index 7318f96e..17ffb5a1 100644
--- a/design/mvp/Explainer.md
+++ b/design/mvp/Explainer.md
@@ -75,6 +75,7 @@ shipped as part of a future WASI Developer Preview release:
 * 📝: the `error-context` type
 * 🔗: canonical interface names
 * 🐘: [memory64]
+* 📡: getters and setters
 
 
 ## Grammar
@@ -2711,8 +2712,8 @@ plainname         ::= <label>
                     | '[constructor]' <label>
                     | '[method]' <label> '.' <label>
                     | '[static]' <label> '.' <label>
-                    | '[get]' <label> '.' <label>
-                    | '[set]' <label> '.' <label>
+                    | '[get]' <label> '.' <label> 📡
+                    | '[set]' <label> '.' <label> 📡
 labellit          ::= '"' <label> '"'
 label             ::= <first-fragment> ( '-' <fragment> )*
 first-fragment    ::= <first-word>
@@ -2748,16 +2749,16 @@ The names of component imports and exports provide two options:
 The `plainname` production captures several language-neutral syntactic hints
 that allow bindings generators to produce more idiomatic bindings in their
 target language. At the top-level, a `plainname` allows functions to be
-annotated as being a constructor, method, getter, setter or static function of
-a preceding resource.
-
-When a function is annotated with `constructor`, `method`, `static`, `get`, or
-`set`, the first `label` is the name of the resource and the second `label` is
-the logical field name of the function. This additional nesting information
-allows bindings generators to insert the function into the nested scope of a
-class, abstract data type, object, namespace, package, module or whatever
-resources get bound to. For example, a function named `[method]C.foo` could be
-bound in C++ to a member function `foo` in a class `C`. The JS API
+annotated as being a constructor, method, 📡 getter, 📡 setter, or static
+function of a preceding resource.
+
+When a function is annotated with `constructor`, `method`, `static`, 📡 `get`,
+or 📡 `set`, the first `label` is the name of the resource and the second
+`label` is the logical field name of the function. This additional nesting
+information allows bindings generators to insert the function into the nested
+scope of a class, abstract data type, object, namespace, package, module or
+whatever resources get bound to. For example, a function named `[method]C.foo`
+could be bound in C++ to a member function `foo` in a class `C`. The JS API
 [below](#JS-API) describes how the native JavaScript bindings could look.
 
 To restrict the set of cases that bindings generators need to consider, these
@@ -2771,7 +2772,7 @@ annotations trigger additional type-validation rules (listed in detail in
   where `$R` is the type-index of the resource type named `R`.
 * An import or export named `[method]R.foo` must be a function whose
   first parameter must be `(param "self" (borrow $R))`.
-* An import or export named `[get|set]R.foo` must be a function whose first
+* 📡 An import or export named `[get|set]R.foo` must be a function whose first
   parameter must be `(param "self" (borrow $R))` and which is required to have
   a result type or second parameter respectively.
 
@@ -2842,35 +2843,45 @@ Values]) are **strongly-unique**:
     2. If the name is `[*]l.l` for any annotation [*] and some `label` `l`,
         replace the name with `l` (e.g. `[method]foo.foo` becomes `foo`).
     3. If the name has any `[...]` annotation prefix other than `[constructor]`
-        or `[set]`, strip it from the name.
+        (📡 or `[set]`), strip it from the name.
 2. The names are strongly-unique if the resulting canonicalized strings are
   unequal.
 
 Thus, the following set of names are strongly-unique and can thus all be imports (or exports) of the same component (or component type or instance type):
 * `foo`, `foo-bar`, `[constructor]foo`, `[method]foo.bar`, `[static]foo.baz`,
-  `foo:bar/baz`, `[get]foo.prop`, `[set]foo.prop`, `[method]foo.get-prop`,
+  `foo:bar/baz`, 📡 `[get]foo.prop`, 📡 `[set]foo.prop`, `[method]foo.get-prop`,
   `[method]foo.set-prop`
 
 but attempting to add *any* of the following names would be a validation error:
 * `foo`, `FOO`, `foo-BAR`, `[constructor]FOO`, `[method]foo.BAR`,
   `[static]foo.bar`, `[method]foo.baz`, `[method]foo.foo`,
-  `[static]foo-BAR.FOO-bar`, `[get]foo.foo`, `foo:bar/BAZ`, `[method]foo.prop`,
-  `[static]foo.PROP`, `[get]foo.PROP`, `[set]foo.PROP`
-
-The purpose of step 1.2 and the `[constructor]` provision of step 1.3 is to
-play nice with constructors: in many languages, a constructor is the only item
-that can have the same name as the class.
+  `[static]foo-BAR.FOO-bar`, `[get]foo.foo`, `foo:bar/BAZ`,
+  📡 `[method]foo.prop`, 📡 `[static]foo.PROP`, 📡 `[get]foo.PROP`,
+  📡 `[set]foo.PROP`
 
 Note that additional validation rules involving types apply to names with
 annotations. For example, the validation rules for `[constructor]foo` require
 `foo` to be a resource type. See [Binary.md](Binary.md#import-and-export-definitions)
 for details.
 
-Note also that `[get]foo.prop` and `[method]foo.get-prop` are considered
-strongly-unique even though in practice they may conflict. If this results in
-a conflict for a bindings generator, the bindings generator may just pick one
-of the two. This is a temporary measure that is expected to be restricted for a
-1.0 release.
+Note that these rules prevent having a method or static function (📡 or getter
+or setter) with the same name as its resource type, leaving room for a
+constructor. This is to satisfy the naming rules around constructors in many
+languages.
+
+📡 Also note that, although `[get]foo.prop` and `[method]foo.prop` are not
+considered strongly-unique, `[set]foo.prop` and `[method]foo.prop` are.
+However, since `[set]foo.prop` separately requires `[get]foo.prop` to be
+present, there is no practical concern of a bindings conflict between
+`[set]foo.prop` and `[method]foo.prop`.
+
+📡 Note also that `[get]foo.prop` and `[method]foo.get-prop` are considered
+strongly-unique even though in practice they may conflict. Likewise,
+`[set]foo.prop` and `[method]foo.set-prop` are considered strongly-unique. If
+this results in a conflict for a bindings generator, the bindings generator may
+choose one of the two and ignore the other. This is a temporary measure: in a
+later release, it is expected that both of these examples will not be
+considered strongly-unique, so API designers are encouraged to avoid this case.
 
 
 #### 🔗 Canonical Interface Name
diff --git a/design/mvp/WIT.md b/design/mvp/WIT.md
index 5954112e..076822e0 100644
--- a/design/mvp/WIT.md
+++ b/design/mvp/WIT.md
@@ -1767,26 +1767,26 @@ transform: func(blob) -> blob;
 
 As syntactic sugar, resource statements can also declare any number of
 *methods*, which are functions that implicitly take a `self` parameter that is
-a handle. A resource statement can also contain any number of *getters* and
-*setters*, which also implicitly take a `self` parameter and have additional
-validation restrictions on their result and parameter types. A resource
-statement can also contain any number of *static functions*, which do not have
-an implicit `self` parameter but are meant to be lexically nested in the scope
-of the resource type. Lastly, a resource statement can contain at most one
-*constructor* function, which is syntactic sugar for a function returning a
-handle of the containing resource type.
+a handle. A resource statement can also contain any number of *static
+functions*, which do not have an implicit `self` parameter but are meant to be
+lexically nested in the scope of the resource type. Lastly, a resource
+statement can contain at most one *constructor* function, which is syntactic
+sugar for a function returning a handle of the containing resource type.
 
 Constructors can be fallible or infallible. Fallible constructors have an
 explicitly-written return type which must be of the form `result<r, ...>` where
 `r` is the name of the containing `resource`. Infallible constructors have no
 written return type and are given the implicit return type `r`.
 
-Getters take no parameters (besides the implicit `self` parameter) and must
-return a value. Setters take exactly one parameter (besides the implicit `self`
-parameter) and may not return a value unless that value is of type
-`result<_, error?>`. If a getter and setter are defined with the same name, and
-the setter's value type is `t`, then the getter's return type must be either
-`t` or `result<t, error?>`.
+📡 A resource statement can also contain any number of *getters* and
+*setters*, which also implicitly take a `self` parameter. Getters take no
+parameters (besides the implicit `self` parameter) and must return a value.
+Setters take exactly one parameter (besides the implicit `self` parameter) and
+may not return a value unless that value is of type `result<_, error?>`. Every
+setter must have a corresponding getter with the same name, and if the setter's
+value type is `t`, then the getter's return type must be either `t` or
+`result<t, error?>`. To simplify validation, the getter must be defined before
+the setter.
 
 For example, the following resource definition:
 ```wit
@@ -1831,8 +1831,8 @@ resource-item ::= 'resource' id ';'
                 | 'resource' id '{' ( gate external-id? resource-method )* '}'
 resource-method ::= func-item
                   | id ':' 'static' func-type ';'
-                  | id ':' 'get' param-list result-list ';'
-                  | id ':' 'set' param-list result-list ';'
+                  | id ':' 'get' param-list result-list ';' 📡
+                  | id ':' 'set' param-list result-list ';' 📡
                   | 'constructor' param-list ';'
 ```
 
@@ -1979,8 +1979,7 @@ is expanded into:
 resource file
 %[method]file.read: func(self: borrow<file>, n: u32) -> list<u8>;
 ```
-where `%[method]file.read` is the desugared name of a method. The same applies
-to the getter and setter syntax.
+where `%[method]file.read` is the desugared name of a method.
 
 
 ## Name resolution

From cb43e7e55fc2acd13121170f5bb11d585c2566b2 Mon Sep 17 00:00:00 2001
From: Ben Visness <bvisness@mozilla.com>
Date: Wed, 19 Aug 2026 13:28:00 -0500
Subject: [PATCH 04/10] Tweaks

---
 design/mvp/Binary.md    | 14 ++++++--------
 design/mvp/Explainer.md |  4 ++--
 design/mvp/WIT.md       | 16 +++++++---------
 3 files changed, 15 insertions(+), 19 deletions(-)

diff --git a/design/mvp/Binary.md b/design/mvp/Binary.md
index 9821aece..faacd44d 100644
--- a/design/mvp/Binary.md
+++ b/design/mvp/Binary.md
@@ -439,16 +439,14 @@ Notes:
   to be `(param "self" (borrow $R))`, where `$R` is the named resource type.
 * 📡 Validation of `[get]` names requires that the function have a single
   parameter `(param "self" (borrow $R))`, where `$R` is the named resource
-  type, and that the function have a return type.
+  type, and that the function have a result type.
 * 📡 Validation of `[set]` names requires that the function have exactly two
   parameters, that the first parameter be `(param "self" (borrow $R))`, and
-  that the function have either no return type or `(result (error $E)?)`.
-* 📡 If `[set]a.b` is defined within a particular scope, then `[get]a.b` must
-  have already been defined in that same scope. (That is, the `label`s must be
-  equal, and the getter must precede the setter.)
-* 📡 If a `[set]` function's second parameter has type `$T`, then its
-  corresponding `[get]` function's result type must be either `$T` or
-  `(result $T (error $E)?)`.
+  that the function have either no result type or `(result (error $E)?)`.
+* 📡 If `[set]a.b` is defined as an import or export within a particular scope,
+  then `[get]a.b` must have already been defined as an import or export
+  respectively in that same scope. (That is, the `label`s must be equal, and
+  the getter must precede the setter.)
 * 🔀/📡 Functions with `[get]` or `[set]` names must not be `async`.
 * 🔗 Validation requires that `versionsuffix` is preceded by an `interfaceversion`
   matching `canonversion` and that the concatenation of the `canonversion` and
diff --git a/design/mvp/Explainer.md b/design/mvp/Explainer.md
index 17ffb5a1..1d63a4b0 100644
--- a/design/mvp/Explainer.md
+++ b/design/mvp/Explainer.md
@@ -2840,7 +2840,7 @@ To determine whether two names (defined as sequences of [Unicode Scalar
 Values]) are **strongly-unique**:
 1. Canonicalize each name:
     1. Lowercase all the `acronym`s (uppercase letters) in the name.
-    2. If the name is `[*]l.l` for any annotation [*] and some `label` `l`,
+    2. If the name is `[*]l.l` for any annotation `[*]` and some `label` `l`,
         replace the name with `l` (e.g. `[method]foo.foo` becomes `foo`).
     3. If the name has any `[...]` annotation prefix other than `[constructor]`
         (📡 or `[set]`), strip it from the name.
@@ -2855,7 +2855,7 @@ Thus, the following set of names are strongly-unique and can thus all be imports
 but attempting to add *any* of the following names would be a validation error:
 * `foo`, `FOO`, `foo-BAR`, `[constructor]FOO`, `[method]foo.BAR`,
   `[static]foo.bar`, `[method]foo.baz`, `[method]foo.foo`,
-  `[static]foo-BAR.FOO-bar`, `[get]foo.foo`, `foo:bar/BAZ`,
+  `[static]foo-BAR.FOO-bar`, 📡 `[get]foo.foo`, `foo:bar/BAZ`,
   📡 `[method]foo.prop`, 📡 `[static]foo.PROP`, 📡 `[get]foo.PROP`,
   📡 `[set]foo.PROP`
 
diff --git a/design/mvp/WIT.md b/design/mvp/WIT.md
index 076822e0..1440a68d 100644
--- a/design/mvp/WIT.md
+++ b/design/mvp/WIT.md
@@ -25,7 +25,7 @@ document, a pseudo-formal [grammar specification][lexical-structure], and
 additionally a specification of the [package format][package-format] of a WIT
 package suitable for distribution.
 
-See [Gated Features] for an explanation of 🔧 and 🏷️.
+See [Gated Features] for an explanation of emoji like 🔧 and 🏷️.
 
 [IDL]: https://en.wikipedia.org/wiki/Interface_description_language
 [components]: https://github.com/webassembly/component-model
@@ -1069,7 +1069,7 @@ keyword ::= 'as'
           | 'from'
           | 'func'
           | 'future'
-          | 'get'
+          | 'get' 📡
           | 'import'
           | 'include'
           | 'interface'
@@ -1085,7 +1085,7 @@ keyword ::= 'as'
           | 's32'
           | 's64'
           | 's8'
-          | 'set'
+          | 'set' 📡
           | 'static'
           | 'stream'
           | 'string'
@@ -1783,10 +1783,8 @@ written return type and are given the implicit return type `r`.
 parameters (besides the implicit `self` parameter) and must return a value.
 Setters take exactly one parameter (besides the implicit `self` parameter) and
 may not return a value unless that value is of type `result<_, error?>`. Every
-setter must have a corresponding getter with the same name, and if the setter's
-value type is `t`, then the getter's return type must be either `t` or
-`result<t, error?>`. To simplify validation, the getter must be defined before
-the setter.
+setter must have a corresponding getter with the same name. To simplify
+validation, the getter must be defined before the setter.
 
 For example, the following resource definition:
 ```wit
@@ -1795,8 +1793,8 @@ resource blob {
     write: func(bytes: list<u8>);
     read: func(n: u32) -> list<u8>;
     merge: static func(lhs: borrow<blob>, rhs: borrow<blob>) -> blob;
-    position: get() -> u64;
-    position: set(value: u64);
+    position: get() -> u64; // 📡
+    position: set(value: u64); // 📡
 }
 resource blob2 {
     constructor(init: list<u8>) -> result<blob2>;

From f230fc02fd62aac17f534def5dd825d653048d96 Mon Sep 17 00:00:00 2001
From: Ben Visness <bvisness@mozilla.com>
Date: Fri, 21 Aug 2026 12:45:21 -0500
Subject: [PATCH 05/10] Add static and interface getters and setters

---
 design/mvp/Binary.md    |  37 +++++++-----
 design/mvp/Explainer.md | 124 +++++++++++++++++++++++-----------------
 design/mvp/WIT.md       |  58 +++++++++++++++----
 3 files changed, 140 insertions(+), 79 deletions(-)

diff --git a/design/mvp/Binary.md b/design/mvp/Binary.md
index faacd44d..ede57960 100644
--- a/design/mvp/Binary.md
+++ b/design/mvp/Binary.md
@@ -422,8 +422,10 @@ Notes:
   type or instance-type must be [strongly-unique]; attributes are ignored.
 * Validation requires that `plainname`s annotated with `[constructor]`,
   `[method]`, `[static]`, 📡 `[get]`, or 📡 `[set]` only occur on `func` imports
-  or exports and that the first `label` of such a name matches the `plainname`
-  of a preceding `resource` import or export, respectively, in the same scope
+  or exports.
+* Validation requires that, for `plainname`s annotated with `[constructor]`,
+  `[method]`, or `[static]`, the first `label` matches the `plainname` of a
+  preceding `resource` import or export, respectively, in the same scope
   (component, component type or instance type).
 * 🏷️ Validation requires that `implements`-annotated imports or exports are
   `instance`-typed and have a `plainname` name.
@@ -433,20 +435,27 @@ Notes:
   `vec(<attribute>)`, this list is entirely ignored when validating the types
   of components and instances.
 * Validation of `[constructor]` names requires a `func` type whose result type
-  is either `(own $R)` or `(result (own $R) E?)`, where `$R` is the named
-  resource type.
+  is either `(own $R)` or `(result (own $R) (error $E)?)`, where `$R` is the
+  named resource type.
 * Validation of `[method]` names requires the first parameter of the function
   to be `(param "self" (borrow $R))`, where `$R` is the named resource type.
-* 📡 Validation of `[get]` names requires that the function have a single
-  parameter `(param "self" (borrow $R))`, where `$R` is the named resource
-  type, and that the function have a result type.
-* 📡 Validation of `[set]` names requires that the function have exactly two
-  parameters, that the first parameter be `(param "self" (borrow $R))`, and
-  that the function have either no result type or `(result (error $E)?)`.
-* 📡 If `[set]a.b` is defined as an import or export within a particular scope,
-  then `[get]a.b` must have already been defined as an import or export
-  respectively in that same scope. (That is, the `label`s must be equal, and
-  the getter must precede the setter.)
+* 📡 Validation of `[get]` names requires that the function have no parameters,
+  unless the name is also annotated with `[method]`, in which case `self` must
+  be the only parameter.
+* 📡 Validation of `[get]` names requires that the function a result type.
+* 📡 Validation of `[set]` names requires that the function have exactly one
+  parameter, unless the name is also annotated with `[method]`, in which case
+  there must be two parameters, the first of which is `self`.
+* 📡 Validation of `[set]` names requires that the function have either no
+  result type or a result type of `(result (error $E)?)`.
+* 📡 If a name with `[set]` is defined as an import or export within a
+  particular scope, the equivalent name with `[get]` must have already been
+  defined in as an import or export respectively in that same scope—that is,
+  all labels must be equal (before canonicalization), and all annotations must
+  be the same except that `[set]` is replaced with `[get]`, and the `[get]`
+  import/export must precede the `[set]` import/export. For example,
+  `[set]prop` requires `[get]prop`, and `[method][set]foo.bar` requires
+  `[method][get]foo.bar`.
 * 🔀/📡 Functions with `[get]` or `[set]` names must not be `async`.
 * 🔗 Validation requires that `versionsuffix` is preceded by an `interfaceversion`
   matching `canonversion` and that the concatenation of the `canonversion` and
diff --git a/design/mvp/Explainer.md b/design/mvp/Explainer.md
index 1d63a4b0..fd19fda0 100644
--- a/design/mvp/Explainer.md
+++ b/design/mvp/Explainer.md
@@ -2709,11 +2709,11 @@ externnamelit     ::= '"' <externname> '"'
 externname        ::= <plainname>
                     | <interfacename>
 plainname         ::= <label>
+                    | '[get]' <label> 📡
+                    | '[set]' <label> 📡
                     | '[constructor]' <label>
-                    | '[method]' <label> '.' <label>
-                    | '[static]' <label> '.' <label>
-                    | '[get]' <label> '.' <label> 📡
-                    | '[set]' <label> '.' <label> 📡
+                    | '[method]' (📡 '[get]' | '[set]')? <label> '.' <label>
+                    | '[static]' (📡 '[get]' | '[set]')? <label> '.' <label>
 labellit          ::= '"' <label> '"'
 label             ::= <first-fragment> ( '-' <fragment> )*
 first-fragment    ::= <first-word>
@@ -2748,33 +2748,36 @@ The names of component imports and exports provide two options:
 
 The `plainname` production captures several language-neutral syntactic hints
 that allow bindings generators to produce more idiomatic bindings in their
-target language. At the top-level, a `plainname` allows functions to be
-annotated as being a constructor, method, 📡 getter, 📡 setter, or static
-function of a preceding resource.
-
-When a function is annotated with `constructor`, `method`, `static`, 📡 `get`,
-or 📡 `set`, the first `label` is the name of the resource and the second
-`label` is the logical field name of the function. This additional nesting
-information allows bindings generators to insert the function into the nested
-scope of a class, abstract data type, object, namespace, package, module or
-whatever resources get bound to. For example, a function named `[method]C.foo`
-could be bound in C++ to a member function `foo` in a class `C`. The JS API
-[below](#JS-API) describes how the native JavaScript bindings could look.
+target language. At the top level, a `plainname` allows functions to be
+annotated as being a constructor, method, 📡 property getter, 📡 property setter,
+or static function of a preceding resource, as well as a 📡 property getter or
+📡 property setter not attached to a resource.
+
+When a function is annotated with `constructor`, `method`, or `static`, the
+first `label` is the name of the resource and the second `label` is the logical
+field name of the function. This additional nesting information allows bindings
+generators to insert the function into the nested scope of a class, abstract
+data type, object, namespace, package, module or whatever resources get bound
+to. For example, a function named `[method]C.foo` could be bound in C++ to a
+member function `foo` in a class `C`. The JS API [below](#JS-API) describes how
+the native JavaScript bindings could look.
 
 To restrict the set of cases that bindings generators need to consider, these
 annotations trigger additional type-validation rules (listed in detail in
 [Binary.md](Binary.md)):
-* An import or export named `[static]R.foo` must be a function and `R` must
-  be the name of an imported or exported resource type in the same `instance`
-  or `component` type.
-* An import or export named `[constructor]R` must be a function
-  whose return type must be `(own $R)` or `(result (own $R) (error <valtype>)?)`
-  where `$R` is the type-index of the resource type named `R`.
-* An import or export named `[method]R.foo` must be a function whose
-  first parameter must be `(param "self" (borrow $R))`.
-* 📡 An import or export named `[get|set]R.foo` must be a function whose first
-  parameter must be `(param "self" (borrow $R))` and which is required to have
-  a result type or second parameter respectively.
+* A `[constructor]` import or export named `R` must be a function whose result
+  type is `(own $R)` or `(result (own $R) (error <valtype>)?)`, where `$R` is
+  the index of the resource type named `R`.
+* A `[method]` import or export named `R.foo` must be a function whose first
+  parameter is `(param "self" (borrow $R))`, where `$R` is the index of the
+  resource type named `R`.
+* A `[static]` import or export named `R.foo` must be a function, and `R` must
+  be the name of a resource type.
+* 📡 A `[get]` import or export must have no parameters (besides the required
+  `self` parameter from `[method]`), and must have a result type.
+* 📡 A `[set]` import or export must have exactly one parameter (besides the
+  required `self` parameter from `[method]`), and must have either no result
+  type or a result type of `(result (error <valtype>)?)`.
 
 The `valid semver` production is as defined by the [Semantic Versioning 2.0]
 spec and is meant to be interpreted according to that specification. The use of
@@ -2838,26 +2841,40 @@ within the same scope.
 
 To determine whether two names (defined as sequences of [Unicode Scalar
 Values]) are **strongly-unique**:
+
 1. Canonicalize each name:
     1. Lowercase all the `acronym`s (uppercase letters) in the name.
-    2. If the name is `[*]l.l` for any annotation `[*]` and some `label` `l`,
-        replace the name with `l` (e.g. `[method]foo.foo` becomes `foo`).
-    3. If the name has any `[...]` annotation prefix other than `[constructor]`
-        (📡 or `[set]`), strip it from the name.
+    2. If the name is `[...]*l.l` for any annotations `[...]*` and some `label`
+        `l`, replace the name with `l` (e.g. `[method]foo.foo` becomes `foo`).
+    3. Strip all `[...]` annotations from the name besides `[constructor]`
+        (📡 and `[set]`).
 2. The names are strongly-unique if the resulting canonicalized strings are
-  unequal.
+    unequal.
+
+Thus, the following set of names are strongly-unique and can thus all be
+imports (or exports) of the same component (or component type or instance
+type):
 
-Thus, the following set of names are strongly-unique and can thus all be imports (or exports) of the same component (or component type or instance type):
 * `foo`, `foo-bar`, `[constructor]foo`, `[method]foo.bar`, `[static]foo.baz`,
-  `foo:bar/baz`, 📡 `[get]foo.prop`, 📡 `[set]foo.prop`, `[method]foo.get-prop`,
-  `[method]foo.set-prop`
+  `foo:bar/baz`, 📡 `[get]prop`, 📡 `[set]prop`, 📡 `[method][get]foo.prop`,
+  📡 `[method][set]foo.prop`, 📡 `[static][get]foo.prop-2`,
+  📡 `[static][set]foo.prop-2`, `[method]foo.get-prop`, `[method]foo.set-prop`
 
 but attempting to add *any* of the following names would be a validation error:
-* `foo`, `FOO`, `foo-BAR`, `[constructor]FOO`, `[method]foo.BAR`,
-  `[static]foo.bar`, `[method]foo.baz`, `[method]foo.foo`,
-  `[static]foo-BAR.FOO-bar`, 📡 `[get]foo.foo`, `foo:bar/BAZ`,
-  📡 `[method]foo.prop`, 📡 `[static]foo.PROP`, 📡 `[get]foo.PROP`,
-  📡 `[set]foo.PROP`
+
+* `foo`, `FOO`, `[method]foo.foo`, 📡 `[get]foo`, 📡 `[method][get]foo.foo`,
+  📡 `[static][set]foo.FOO` (conflicts with `foo`)
+* `foo-BAR`, `[static]foo-BAR.FOO-bar` (conflicts with `foo-bar`)
+* `[constructor]FOO` (conflicts with `[constructor]foo`)
+* `[method]foo.BAR`, `[static]foo.bar` (conflicts with `[method]foo.bar`)
+* `[method]foo.baz` (conflicts with `[static]foo.baz`)
+* `foo:bar/BAZ` (conflicts with `foo:bar/baz`)
+* 📡 `prop` (conflicts with `[get]prop`)
+* 📡 `[set]PROP` (conflicts with `[set]prop`)
+* 📡 `[method]foo.prop`, 📡 `[static]foo.PROP`, 📡 `[method][get]foo.PROP`,
+  📡 `[static][get]foo.prop` (conflicts with `[method][get]foo.prop`)
+* 📡 `[method][set]foo.PROP`, 📡 `[static][set]foo.prop` (conflicts with
+  `[method][set]foo.prop`)
 
 Note that additional validation rules involving types apply to names with
 annotations. For example, the validation rules for `[constructor]foo` require
@@ -2869,19 +2886,20 @@ or setter) with the same name as its resource type, leaving room for a
 constructor. This is to satisfy the naming rules around constructors in many
 languages.
 
-📡 Also note that, although `[get]foo.prop` and `[method]foo.prop` are not
-considered strongly-unique, `[set]foo.prop` and `[method]foo.prop` are.
-However, since `[set]foo.prop` separately requires `[get]foo.prop` to be
-present, there is no practical concern of a bindings conflict between
-`[set]foo.prop` and `[method]foo.prop`.
-
-📡 Note also that `[get]foo.prop` and `[method]foo.get-prop` are considered
-strongly-unique even though in practice they may conflict. Likewise,
-`[set]foo.prop` and `[method]foo.set-prop` are considered strongly-unique. If
-this results in a conflict for a bindings generator, the bindings generator may
-choose one of the two and ignore the other. This is a temporary measure: in a
-later release, it is expected that both of these examples will not be
-considered strongly-unique, so API designers are encouraged to avoid this case.
+📡 Also note that, although `[get]foo` and `foo` are not considered
+strongly-unique, `[set]foo` and `foo` are. However, since `[set]foo` separately
+requires `[get]foo` to be present, there is no practical concern of a bindings
+conflict between `[set]foo` and `foo`. The same goes for other uses of `[get]`
+and `[set]` annotations.
+
+📡 Note also that `[method][get]foo.prop` and `[method]foo.get-prop` are
+considered strongly-unique even though in practice they may conflict. Likewise,
+`[method][set]foo.prop` and `[method]foo.set-prop` are considered
+strongly-unique. If this results in a conflict for a bindings generator, the
+bindings generator may choose one of the two and ignore the other. This is a
+temporary measure: in a later release, it is expected that both of these
+examples will not be considered strongly-unique, so API designers are
+encouraged to avoid this case.
 
 
 #### 🔗 Canonical Interface Name
diff --git a/design/mvp/WIT.md b/design/mvp/WIT.md
index 1440a68d..eb694e9a 100644
--- a/design/mvp/WIT.md
+++ b/design/mvp/WIT.md
@@ -1559,6 +1559,8 @@ typedef-item ::= resource-item
 func-item ::= id ':' func-type ';'
 
 func-type ::= 'async'? 'func' param-list result-list
+            | 'get' param-list result-list
+            | 'set' param-list result-list
 
 param-list ::= '(' named-type-list ')'
 
@@ -1577,6 +1579,29 @@ source-language bindings (e.g., `async` functions in JS, Python, C# or Rust) if
 concurrency execution is desired. For more details, see the [concurrency
 explainer](Concurrency.md#summary).
 
+📡 As syntactic sugar, functions can be declared as *getters* or *setters* by
+replacing the `func` keyword with `get` or `set`. Such functions cannot be
+async and have additional restrictions on their parameters and results. A `get`
+function must have no parameters and must return a value. A `set` function
+must have exactly one parameter and must not return a value unless that value
+is of type `result<_, error?>`. Every setter must have a corresponding getter
+with the same name. To simplify validation, the getter must be defined before
+the setter. For example, the following definitions:
+
+```wit
+foo: func(x: u32);
+bar: get() -> u64;
+bar: set(v: u64);
+```
+
+desugar into:
+
+```wit
+foo: func(x: u32);
+[get]bar: func() -> u64;
+[set]bar: func(v: u64);
+```
+
 🏷️ As with `import`s and `export`s in worlds, and for the same use cases,
 interface items can be annotated with `@external-id`:
 ```wit
@@ -1779,14 +1804,16 @@ explicitly-written return type which must be of the form `result<r, ...>` where
 written return type and are given the implicit return type `r`.
 
 📡 A resource statement can also contain any number of *getters* and
-*setters*, which also implicitly take a `self` parameter. Getters take no
-parameters (besides the implicit `self` parameter) and must return a value.
-Setters take exactly one parameter (besides the implicit `self` parameter) and
-may not return a value unless that value is of type `result<_, error?>`. Every
-setter must have a corresponding getter with the same name. To simplify
+*setters*, which may or may not be static. Non-static getters and setters also
+implicitly take a `self` parameter. Getters take no parameters (besides the
+implicit `self` parameter) and must return a value. Setters take exactly one
+parameter (besides the implicit `self` parameter) and must not return a value
+unless that value is of type `result<_, error?>`. Every setter must have a
+corresponding getter with the same name and same static-ness. To simplify
 validation, the getter must be defined before the setter.
 
-For example, the following resource definition:
+For example, the following resource definitions:
+
 ```wit
 resource blob {
     constructor(init: list<u8>);
@@ -1795,22 +1822,29 @@ resource blob {
     merge: static func(lhs: borrow<blob>, rhs: borrow<blob>) -> blob;
     position: get() -> u64; // 📡
     position: set(value: u64); // 📡
+    max-size: static get() -> u64; // 📡
+    max-size: static set(value: u64) -> result<_, string>; // 📡
 }
 resource blob2 {
     constructor(init: list<u8>) -> result<blob2>;
 }
 ```
-desugars into:
+
+desugar into:
+
 ```wit
 resource blob;
 %[constructor]blob: func(init: list<u8>) -> blob;
-%[constructor]blob2: func(init: list<u8>) -> result<blob2>;
 %[method]blob.write: func(self: borrow<blob>, bytes: list<u8>);
 %[method]blob.read: func(self: borrow<blob>, n: u32) -> list<u8>;
 %[static]blob.merge: func(lhs: borrow<blob>, rhs: borrow<blob>) -> blob;
-%[get]blob.position: func(self: borrow<blob>) -> u64;
-%[set]blob.position: func(self: borrow<blob>, value: u64);
+%[method][get]blob.position: func(self: borrow<blob>) -> u64;
+%[method][set]blob.position: func(self: borrow<blob>, value: u64);
+%[static][get]blob.max-size: func() -> u64;
+%[static][set]blob.max-size: func(value: u64) -> result<_, string>;
+%[constructor]blob2: func(init: list<u8>) -> result<blob2>;
 ```
+
 These `%`-prefixed strings embed the resource type name so that bindings
 generators can generate idiomatic syntax for the target language or (for
 languages like C) fall back to an appropriately-prefixed free function name.
@@ -1829,8 +1863,8 @@ resource-item ::= 'resource' id ';'
                 | 'resource' id '{' ( gate external-id? resource-method )* '}'
 resource-method ::= func-item
                   | id ':' 'static' func-type ';'
-                  | id ':' 'get' param-list result-list ';' 📡
-                  | id ':' 'set' param-list result-list ';' 📡
+                  | id ':' 'static'? 'get' param-list result-list ';' 📡
+                  | id ':' 'static'? 'set' param-list result-list ';' 📡
                   | 'constructor' param-list ';'
 ```
 

From b08dd0b02da2f37d029e7e6e1d3737c32b0eabc5 Mon Sep 17 00:00:00 2001
From: Ben Visness <bvisness@mozilla.com>
Date: Fri, 21 Aug 2026 12:59:32 -0500
Subject: [PATCH 06/10] Fixes from review

---
 design/mvp/Binary.md    | 8 ++++----
 design/mvp/Explainer.md | 7 ++++---
 design/mvp/WIT.md       | 6 ++----
 3 files changed, 10 insertions(+), 11 deletions(-)

diff --git a/design/mvp/Binary.md b/design/mvp/Binary.md
index ede57960..08315a8c 100644
--- a/design/mvp/Binary.md
+++ b/design/mvp/Binary.md
@@ -442,7 +442,7 @@ Notes:
 * 📡 Validation of `[get]` names requires that the function have no parameters,
   unless the name is also annotated with `[method]`, in which case `self` must
   be the only parameter.
-* 📡 Validation of `[get]` names requires that the function a result type.
+* 📡 Validation of `[get]` names requires that the function have a result type.
 * 📡 Validation of `[set]` names requires that the function have exactly one
   parameter, unless the name is also annotated with `[method]`, in which case
   there must be two parameters, the first of which is `self`.
@@ -450,9 +450,9 @@ Notes:
   result type or a result type of `(result (error $E)?)`.
 * 📡 If a name with `[set]` is defined as an import or export within a
   particular scope, the equivalent name with `[get]` must have already been
-  defined in as an import or export respectively in that same scope—that is,
-  all labels must be equal (before canonicalization), and all annotations must
-  be the same except that `[set]` is replaced with `[get]`, and the `[get]`
+  defined as an import or export respectively in that same scope—that is, all
+  labels must be equal (before canonicalization), and all annotations must be
+  the same except that `[set]` is replaced with `[get]`, and the `[get]`
   import/export must precede the `[set]` import/export. For example,
   `[set]prop` requires `[get]prop`, and `[method][set]foo.bar` requires
   `[method][get]foo.bar`.
diff --git a/design/mvp/Explainer.md b/design/mvp/Explainer.md
index fd19fda0..67ce2334 100644
--- a/design/mvp/Explainer.md
+++ b/design/mvp/Explainer.md
@@ -2847,7 +2847,7 @@ Values]) are **strongly-unique**:
     2. If the name is `[...]*l.l` for any annotations `[...]*` and some `label`
         `l`, replace the name with `l` (e.g. `[method]foo.foo` becomes `foo`).
     3. Strip all `[...]` annotations from the name besides `[constructor]`
-        (📡 and `[set]`).
+        and 📡 `[set]`.
 2. The names are strongly-unique if the resulting canonicalized strings are
     unequal.
 
@@ -3097,8 +3097,9 @@ object*] steps need to be expanded to cover them:
 
 For type exports, each type definition would export a JS constructor function.
 This function would be callable iff a `[constructor]`-annotated function was
-also exported. All `[method]`- and `[static]`-annotated functions would be
-dynamically installed on the constructor's prototype chain. In the case of
+also exported. All `[method]`- and `[static]`-annotated functions, would be
+dynamically installed on the constructor's prototype chain, making sure to
+register `[get]` and `[set]` functions as getters and setters. In the case of
 re-exports and multiple exports of the same definition, the same constructor
 function object would be exported (following the same rules as WebAssembly
 Exported Functions today). In pathological cases (which, importantly, don't
diff --git a/design/mvp/WIT.md b/design/mvp/WIT.md
index eb694e9a..51d1acbc 100644
--- a/design/mvp/WIT.md
+++ b/design/mvp/WIT.md
@@ -1559,8 +1559,8 @@ typedef-item ::= resource-item
 func-item ::= id ':' func-type ';'
 
 func-type ::= 'async'? 'func' param-list result-list
-            | 'get' param-list result-list
-            | 'set' param-list result-list
+            | 'get' param-list result-list 📡
+            | 'set' param-list result-list 📡
 
 param-list ::= '(' named-type-list ')'
 
@@ -1863,8 +1863,6 @@ resource-item ::= 'resource' id ';'
                 | 'resource' id '{' ( gate external-id? resource-method )* '}'
 resource-method ::= func-item
                   | id ':' 'static' func-type ';'
-                  | id ':' 'static'? 'get' param-list result-list ';' 📡
-                  | id ':' 'static'? 'set' param-list result-list ';' 📡
                   | 'constructor' param-list ';'
 ```
 

From 56a2d2356e5f9b22a8cb3976aaeb46d01e3cc13a Mon Sep 17 00:00:00 2001
From: Ben Visness <bvisness@mozilla.com>
Date: Fri, 21 Aug 2026 14:04:44 -0500
Subject: [PATCH 07/10] Remove get-before-set rule from WIT only

---
 design/mvp/WIT.md | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/design/mvp/WIT.md b/design/mvp/WIT.md
index 51d1acbc..421541ef 100644
--- a/design/mvp/WIT.md
+++ b/design/mvp/WIT.md
@@ -1809,8 +1809,7 @@ implicitly take a `self` parameter. Getters take no parameters (besides the
 implicit `self` parameter) and must return a value. Setters take exactly one
 parameter (besides the implicit `self` parameter) and must not return a value
 unless that value is of type `result<_, error?>`. Every setter must have a
-corresponding getter with the same name and same static-ness. To simplify
-validation, the getter must be defined before the setter.
+corresponding getter with the same name and same static-ness.
 
 For example, the following resource definitions:
 

From 417e0eaa04b776e925304236f8f9b6e60810a539 Mon Sep 17 00:00:00 2001
From: Ben Visness <bvisness@mozilla.com>
Date: Fri, 21 Aug 2026 14:17:54 -0500
Subject: [PATCH 08/10] Rogue comma

---
 design/mvp/Explainer.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/design/mvp/Explainer.md b/design/mvp/Explainer.md
index 67ce2334..e545c18e 100644
--- a/design/mvp/Explainer.md
+++ b/design/mvp/Explainer.md
@@ -3097,7 +3097,7 @@ object*] steps need to be expanded to cover them:
 
 For type exports, each type definition would export a JS constructor function.
 This function would be callable iff a `[constructor]`-annotated function was
-also exported. All `[method]`- and `[static]`-annotated functions, would be
+also exported. All `[method]`- and `[static]`-annotated functions would be
 dynamically installed on the constructor's prototype chain, making sure to
 register `[get]` and `[set]` functions as getters and setters. In the case of
 re-exports and multiple exports of the same definition, the same constructor

From bbcfc9fcba0b74409a9809d9fc740b861da8d405 Mon Sep 17 00:00:00 2001
From: Ben Visness <bvisness@mozilla.com>
Date: Mon, 24 Aug 2026 12:06:24 -0500
Subject: [PATCH 09/10] Remove reserved keywords, add clarifying [method] note

---
 design/mvp/Binary.md | 5 +++--
 design/mvp/WIT.md    | 2 --
 2 files changed, 3 insertions(+), 4 deletions(-)

diff --git a/design/mvp/Binary.md b/design/mvp/Binary.md
index 08315a8c..6bcfcca3 100644
--- a/design/mvp/Binary.md
+++ b/design/mvp/Binary.md
@@ -441,11 +441,12 @@ Notes:
   to be `(param "self" (borrow $R))`, where `$R` is the named resource type.
 * 📡 Validation of `[get]` names requires that the function have no parameters,
   unless the name is also annotated with `[method]`, in which case `self` must
-  be the only parameter.
+  be the only parameter (subject to the `[method]` validation rules above).
 * 📡 Validation of `[get]` names requires that the function have a result type.
 * 📡 Validation of `[set]` names requires that the function have exactly one
   parameter, unless the name is also annotated with `[method]`, in which case
-  there must be two parameters, the first of which is `self`.
+  there must be two parameters, the first of which is `self` (subject to the
+  `[method]` validation rules above).
 * 📡 Validation of `[set]` names requires that the function have either no
   result type or a result type of `(result (error $E)?)`.
 * 📡 If a name with `[set]` is defined as an import or export within a
diff --git a/design/mvp/WIT.md b/design/mvp/WIT.md
index 421541ef..0f16496e 100644
--- a/design/mvp/WIT.md
+++ b/design/mvp/WIT.md
@@ -1069,7 +1069,6 @@ keyword ::= 'as'
           | 'from'
           | 'func'
           | 'future'
-          | 'get' 📡
           | 'import'
           | 'include'
           | 'interface'
@@ -1085,7 +1084,6 @@ keyword ::= 'as'
           | 's32'
           | 's64'
           | 's8'
-          | 'set' 📡
           | 'static'
           | 'stream'
           | 'string'

From 3572b56b2a6202b16661c99c3be8ec872af60ddc Mon Sep 17 00:00:00 2001
From: Ben Visness <bvisness@mozilla.com>
Date: Mon, 24 Aug 2026 18:54:01 -0500
Subject: [PATCH 10/10] Remove rogue order requirement

---
 design/mvp/WIT.md | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/design/mvp/WIT.md b/design/mvp/WIT.md
index 0f16496e..739fda38 100644
--- a/design/mvp/WIT.md
+++ b/design/mvp/WIT.md
@@ -1583,8 +1583,7 @@ async and have additional restrictions on their parameters and results. A `get`
 function must have no parameters and must return a value. A `set` function
 must have exactly one parameter and must not return a value unless that value
 is of type `result<_, error?>`. Every setter must have a corresponding getter
-with the same name. To simplify validation, the getter must be defined before
-the setter. For example, the following definitions:
+with the same name. For example, the following definitions:
 
 ```wit
 foo: func(x: u32);
@@ -1592,7 +1591,7 @@ bar: get() -> u64;
 bar: set(v: u64);
 ```
 
-desugar into:
+will desugar into:
 
 ```wit
 foo: func(x: u32);