std.fmt.format — with streams

[fengb]

Spiritual successor to #4059. Thanks to @daurnimator for suggesting this approach.

Like generators, we can coalesce context/output/error into one argument.

Unlike generators, we don't have to invent a new pattern. OutStream is already an existing standard, and we just have to leverage its functionality. This also circumvents the previously encountered generator footguns since we have at most 1 async context.

The major downside is that OutStream is currently "all or nothing" when it comes to async, which would prevent non-async version of format(). Not sure how much of a problem this is and it's not specific to just format(), and this could be solvable by introducing noasync OutStreams (yay colors?)
solved via #4710

[ikskuh]

The major downside is that OutStream is currently "all or nothing" when it comes to async, which would prevent non-async version of format(). Not sure how much of a problem this is and it's not specific to just format(), and this could be solvable by introducing noasync OutStreams (yay colors?)

I think this can be a major problem when doing user interfaces. I use std.fmt primarily for user interaction and UI formatting. Requiring std.fmt.format to be async because it's using streams would mean that even just setting the text of a label would require to be async. Sure one can use noasync, but i actually like the current approach to format.

[fengb]

@MasterQ32 I think the new OutStream rewrite solves the always-async problem, and it exposes that the concept of an OutStream is just Context, Error, writeFn glued together into one.

[fengb]

Now that the stream is readily available, maybe this method should be deleted.

[andrewrk]

This idea is approved ✔️ but I haven't reviewed the PR yet