[0.3.0-draft] No way to communicate error-on-write via stdio streams

[alexcrichton]

There's no future<error-thing> or related, so if a host encounters an error during a write it's forced to swallow it at this time.

[alexcrichton]

cc @lann on this (as a newly-added co-chair) this'd be something good to resolve before the next snapshot in a few weeks (e.g. close as invalid or add a future/async thing somewhere)

[lann]

A naive answer would be going back to e.g. get-stdout: func() -> descriptor. I'm trying to unearth context on any rationale for the current design.

[alexcrichton]

In WASIp2 it was get-stdout: func() -> output-stream and so the current rationale is "well output-stream went away so let's use stream<u8> instead" AFAIK. Streams are a reader type unlike output-stream which was a writer, hence the inversion.

I'd be hesitant to return a full-blown descriptor in that it would introduce a dependency of wasi:cli/stdout on filesystem bits and also pulls in a lot of functions that would otherwise almost always return an error. I may not be thinking enough outside the box though

[sunfishcode]

wasi-filesystem's write-via-stream would seem to be in the same boat.

Perhaps the answer is for these kinds of functions to take both a stream and a future as parameters, following the pattern of other streams we have that can fail. Edit: On further consideration, that won't work as we need the error to be reported from the callee, not the caller.