Make 'async' part of the function type, not a hint

Author: lukewagner

design/mvp/Binary.md

@@ -216,6 +216,7 @@ valtype       ::= i:<typeidx>                             => i
 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)
+                | 0x43 ps:<paramlist> rs:<resultlist>     => (func async ps rs)
 paramlist     ::= lt*:vec(<labelvaltype>)                 => (param lt)*
 resultlist    ::= 0x00 t:<valtype>                        => (result t)
                 | 0x01 0x00                               =>

design/mvp/Explainer.md

@@ -568,7 +568,7 @@ valtype       ::= <typeidx>
                 | <defvaltype>
 resourcetype  ::= (resource (rep i32) (dtor <funcidx>)?)
                 | (resource (rep i32) (dtor async <funcidx> (callback <funcidx>)?)?) 🚝
-functype      ::= (func (param "<label>" <valtype>)* (result <valtype>)?)
+functype      ::= (func async? (param "<label>" <valtype>)* (result <valtype>)?)
 componenttype ::= (component <componentdecl>*)
 instancetype  ::= (instance <instancedecl>*)
 componentdecl ::= <importdecl>
@@ -737,11 +737,8 @@ are useful for:
 
 A `future<T>` asynchronously delivers exactly one `T` value from a source to a
 destination, unless the destination signals that it doesn't want the `T` value
-any more. Because [all imports can be called asynchronously][summary], futures
-are not necessary to express a traditional `async` function -- all functions
-are effectively `async`. Instead futures are useful in more advanced scenarios
-where a parameter or result value may not be ready at the same time as the
-other synchronous parameters or results.
+any more. When function types are marked [`async`][summary] directly,
+...TODO... `future<T>` is only needed to express *additional* concurrency.
 
 The `T` element type of `stream` and `future` is an optional `valtype`. As with
 variant-case payloads and function results, when `T` is absent, the "value(s)"
@@ -793,7 +790,9 @@ shared-nothing functions, resources, components, and component instances:
 
 The `func` type constructor describes a component-level function definition
 that takes a list of `valtype` parameters with [strongly-unique] names and
-optionally returns a `valtype`.
+optionally returns a `valtype`. The optional `async` effect type indicates that
+the function may block (calling a blocking built-in like `waitable-set.wait` or
+synchronously calling an imported `async` function).
 
 The `resource` type constructor creates a fresh type for each instance of the
 containing component (with "freshness" and its interaction with general
@@ -2521,12 +2520,9 @@ importname        ::= <exportname>
                     | <urlname>
                     | <hashname>
 plainname         ::= <label>
-                    | '[async]' <label> 🔀
                     | '[constructor]' <label>
                     | '[method]' <label> '.' <label>
-                    | '[async method]' <label> '.' <label> 🔀
                     | '[static]' <label> '.' <label>
-                    | '[async static]' <label> '.' <label> 🔀
 label             ::= <fragment>
                     | <label> '-' <fragment>
 fragment          ::= <word>
@@ -2671,10 +2667,10 @@ annotations trigger additional type-validation rules (listed in
 * Similarly, an import or export named `[method]R.foo` must be a function whose
   first parameter must be `(param "self" (borrow $R))`.
 
-When a function is annotated with `async`, bindings generators are expected to
+When a function's type is `async`, bindings generators are expected to
 emit whatever asynchronous language construct is appropriate (such as an
-`async` function in JS, Python or Rust). Note the absence of
-`[async constructor]`. See the [concurrency explainer] for more details.
+`async` function in JS, Python or Rust). See the [concurrency explainer] for
+more details.
 
 The `label` production used inside `plainname` as well as the labels of
 `record` and `variant` types are required to have [kebab case]. The reason for
@@ -2806,7 +2802,8 @@ Thus, the following names are strongly-unique:
 * `foo`, `foo-bar`, `[constructor]foo`, `[method]foo.bar`, `[method]foo.baz`
 
 but attempting to add *any* of the following names would be a validation error:
-* `foo`, `foo-BAR`, `[constructor]foo-BAR`, `[method]foo.foo`, `[async]foo`, `[method]foo.BAR`
+* `foo`, `foo-BAR`, `[constructor]foo-BAR`, `[method]foo.foo`,
+  `[static]foo.foo`, `[method]foo.BAR`
 
 Note that additional validation rules involving types apply to names with
 annotations. For example, the validation rules for `[constructor]foo` require

design/mvp/WIT.md

@@ -1450,16 +1450,11 @@ named-type-list ::= ϵ
 named-type ::= id ':' ty
 ```
 
-The optional `async` hint in a WIT function type indicates that the callee
-is expected to block and thus the caller should emit whatever asynchronous
-language bindings are appropriate (e.g., in JS, Python, C# or Rust, an `async`
-WIT function would emit an `async` JS/Python/C#/Rust function). Because `async`
-is just a hint and not enforced by the runtime, it is technically possible for
-a non-`async` callee to block. In that case, though, it is the *callee's* fault
-for any resultant loss of concurrency, not the caller's. Thus, `async` is
-primarily intended to document expectations in a way that can be taken
-advantage of by bindings generators. (For more details, see the [concurrency
-explainer](Concurrency.md).)
+The optional `async` prefix in a WIT function type indicates that the callee is
+allowed to block and thus the caller should emit the appropriate asynchronous
+source-language bindings (e.g., in JS, Python, C# or Rust, an `async` WIT
+function would emit an `async` JS/Python/C#/Rust function). (For more details,
+see the [concurrency explainer](Concurrency.md).)
 
 
 ## Item: `use`
@@ -1689,8 +1684,8 @@ resource-method ::= func-item
                   | 'constructor' param-list ';'
 ```
 
-The optional `async` hint on `static` functions has the same meaning as
-in a non-`static` `func-item`.
+The optional `async` on `static` functions has the same meaning as in a
+non-`static` `func-item`.
 
 The syntax for handle types is presented [below](#handles).