witx should encode ok/error result types

[pchickey]

All of the WASI APIs currently return errno, and take other return values as mutable output buffers (see #155). This makes sense as a C ABI. But, since our goal is language independence, we should encode this property in a way that permits idiomatic representations in other languages.

In effect, all output buffers are valid iff the errno is success, and invalid otherwise. This is captured in an ADT in many languages, e.g. Rust's Result<a, e>.

Currently, code generators like https://github.com/bytecodealliance/wasi/tree/master/crates/generate-raw transform the WASI APIs into idiomatic ones by a special case that knows about this convention. These generators would be more flexible, and useful for non-wasi witx interfaces, if this was not a special case.

One approach is to add new fields in each @interface func def, (@witx result-ok $name $ty) and (@witx result-err $ty). This would desugar to an identical C ABI as we currently have, but make it clear that the (exactly 1) result-err is the error case, and the 0 or more result-ok are the success case.

Another approach is to add full ADT & generics support to witx, and return a result enum like in Rust. That seems like a lot more work, even though I think we do eventually want ADTs and generics in witx.

[sunfishcode]

I like the idea of encoding higher-level semantics in witx in general. I wonder if result-err is too specialized for this one use case though.

Brainstorm: what if we added four relatively simple things: a discriminated union (variant) type, a unit type, a boolean type, and a non-zero integer type? This wouldn't need generics; it might just look something like:

(typename $error (nonzero u32))
(typename $success (unit))

(typename $errno
  (variant bool
    (case false $success)
    (case true $error)
  )
)

We'd have several other uses for variants too, because all of our unions are really discriminated, eg:

(typename $subscription_u
  (variant $eventtype
    (case $clock $subscription_clock)
    (case $fd_readwrite $subscription_fd_readwrite)
  )
)

and others.

One subtlety: what happens if there's a variant function parameter and the user passes an invalid discriminator? I think we can say that's an EINVAL or so. Similar if the user passes in a zero to a nonzero parameter (if we ever have those).

[sunfishcode]

This is implemented in #395, with the new result type in witx.