Add 'non-blocking' function attribute

design/mvp/Async.md

@@ -22,6 +22,7 @@ summary of the motivation and animated sketch of the design in action.
   * [Backpressure](#backpressure)
   * [Returning](#returning)
 * [Examples](#examples)
+* [Bindings Generation](#bindings-generation)
 * [Interaction with multi-threading](#interaction-with-multi-threading)
 * [Interaction with the start function](#interaction-with-the-start-function)
 * [TODO](#todo)
@@ -539,6 +540,11 @@ return values from `task.wait` in the previous example. The precise meaning of
 these values is defined by the Canonical ABI.
 
 
+## Bindings Generation
+
+TODO
+
+
 ## Interaction with multi-threading
 
 For now, the integration between multi-threading (via [`thread.spawn`]) and

design/mvp/Binary.md

@@ -214,7 +214,11 @@ valtype       ::= i:<typeidx>                             => i
                 | pvt:<primvaltype>                       => pvt
 resourcetype  ::= 0x3f 0x7f f?:<funcidx>?                 => (resource (rep i32) (dtor f)?)
                 | 0x3e 0x7f f:<funcidx> cb?:<funcidx>?    => (resource (rep i32) (dtor async f (callback cb)?))
-functype      ::= 0x40 ps:<paramlist> rs:<resultlist>     => (func ps rs)
+functype      ::= 0x40 sig:<funcsig>                      => (func sig)
+                | 0x3d attrs:<funcattrs> sig:<funcsig>    => (func attrs sig)
+funcattrs     ::= 0x00                                    =>
+                | 0x01                                    => non-blocking
+funcsig       ::= ps:<paramlist> rs:<resultlist>          => ps rs
 paramlist     ::= lt*:vec(<labelvaltype>)                 => (param lt)*
 resultlist    ::= 0x00 t:<valtype>                        => (result t)
                 | 0x01 0x00                               =>
@@ -487,6 +491,7 @@ named once.
 * The opcodes (for types, canon built-ins, etc) should be re-sorted
 * The two `list` type codes should be merged into one with an optional immediate.
 * The `0x00` prefix byte of `importname'` and `exportname'` will be removed or repurposed.
+* Merge the two `functype` opcodes
 
 
 [`core:byte`]: https://webassembly.github.io/spec/core/binary/values.html#binary-byte

design/mvp/Explainer.md

@@ -560,7 +560,7 @@ defvaltype    ::= bool
 valtype       ::= <typeidx>
                 | <defvaltype>
 resourcetype  ::= (resource (rep i32) (dtor async? <funcidx> (callback <funcidx>)?)?)
-functype      ::= (func (param "<label>" <valtype>)* (result <valtype>)?)
+functype      ::= (func non-blocking? (param "<label>" <valtype>)* (result <valtype>)?)
 componenttype ::= (component <componentdecl>*)
 instancetype  ::= (instance <instancedecl>*)
 componentdecl ::= <importdecl>
@@ -785,6 +785,17 @@ The `func` type constructor describes a component-level function definition
 that takes a list of uniquely-named `valtype` parameters and optionally returns
 a `valtype`.
 
+Function types can optionally be annotated with the `non-blocking` attribute.
+This attribute has no semantic effect and is ignored by type-checking. Instead,
+`non-blocking` indicates that even highly-concurrent callers otherwise using
+[async](Async.md) *should* (not *must*) always make a sychronous call. Since
+`non-blocking` has no semantic effect, the callee may in fact block (and for
+valid reasons, e.g., in performance-insensitive virtualization scenarios), but
+the presence of `non-blocking` makes any resultant performance loss the
+*callee's* fault. Thus `non-blocking` is primarily intended to set expectations
+when defining language-agnostic (WIT) interfaces and inform default bindings
+generation.
+
 The `resource` type constructor creates a fresh type for each instance of the
 containing component (with "freshness" and its interaction with general
 type-checking described in more detail [below](#type-checking)). Resource types
@@ -1309,7 +1320,8 @@ can be applied to any component-level function type and changes the derived
 Canonical ABI significantly. See the [async explainer](Async.md) for more
 details. When a function signature contains a `future` or `stream`, validation
 of `canon lower` requires the `async` option to be set (since a synchronous
-call to a function using these types is highly likely to deadlock).
+call to a function using these types is highly likely to deadlock). Conversely,
+`async` may *not* be set if `canon lower`ing a `non-blocking` function.
 
 🔀 The `(callback ...)` option may only be present in `canon lift` when the
 `async` option has also been set and specifies a core function that is