> The async block as I'm picturing it has nothing to do with function colouring, it's
> about the outermost function in an async stack being able to say "make sure the scheduler is
> started" and "block here until all child fibers are either concluded, detached, or
> cancelled".
There's no need for such a construct, as the awaitAll function does precisely what you
describe, without the need to introduce the concept of a child fiber and the excessive limitation of
an async block that severely limits concurrency.
There is absolutely nothing wrong with the concept of a fiber without a parent, or a fiber that
throws an exception (or a cancellation exception) out of the event loop.
A panic in a golang fiber surfaces out of the event loop (unless it is catched with a recover), just
like an uncatched exception in a fiber surfaces out of the event loop: it makes no sense to severely
limit concurrency with an async block just to handle the edge case of an uncaught exception (which
can be handled anyway with an event loop exception handler).
In general, I really don't like the concept of an async block the way it is presented here,
because it implies that concurrency is something bad that must be limited and controlled, or else
bad stuff will happen, when in reality, a fiber throwing an exception (without anyone await()ing on
the fiber handle, thus throwing out of the event loop) is not the end of the world, and can be
handled by other means, without limiting concurrency.
Regards,
Daniil Gentili.