> I think you've misunderstood what I meant by optional. I meant that putting the fiber into
> the managed context would be optional *at the point where the fiber was spawned*.
>
> It sounds like you think:
>
> 1) The language absolutely needs a "spawn detached" operation, i.e. a way of starting
> a new fiber which is queued in the global scheduler, but has no automatic relationship to its
> parent.
> 2) If the language offered both "spawn managed" and "spawn detached", the
> "detached" mode would be overwhelmingly more common (i.e. users and library authors would
> want to manage the lifecycle of their coroutines manually), so the "spawn managed" mode
> isn't worth implementing.
>
> Would that be a fair summary of your opinion?
Indeed, yes! That would be a complete summary of my opinion.
If the user could choose whether to add fibers to the managed context or not, that would be more
acceptable IMO.
Then again see point 2, plus even an optional managed fiber context still introduces a certain
degree of "magicness" and non-obvious/implicit behavior on initiative of the caller, that
can be avoided by simply explicitly returning and awaiting any spawned fibers.
Regards,
Daniil Gentili.