> > You already explicitly await all fibers spawned in the generateReport function, you get all the data you need, any extra spawned fibers should not interest you for the purpose of the logic of generateReport. >
In this specific code, it only awaits the tasks it has launched itself. So, if another function mistakenly starts a coroutine in the current `Scope`, that coroutine will be cancelled when the scope is destroyed. On the other hand, code that does `await $scope` assumes that the programmer *intends* to wait for everything and understands the implications. This usually means that the functions being called are part of the same module and are designed with this in mind. As for library functions — **library functions MUST understand what they are doing**. If a library function creates resources indiscriminately and doesn’t clean them up, the language cannot be held responsible. If library functions don’t manage resource ownership properly, the language cannot take responsibility for that either. > > This is because again, the main use case listed of making sure all fibers are done after a request is a footgun is a non-business-logic requirement, > an exercise in functional purity that also reduces caching and concurrency opportunities, as mentioned before. > In this RFC, there is no such primary use case. There is the `await $scope` construct, but it can no longer be used as the default. There used to be a `await currentScope()` construct, which was a footgun — but it will no longer exist. I also removed `globalScope`, because in 99% of cases it’s an anti-pattern and can be easily replaced with code that creates a coroutine in a separate `Scope`. Through writing examples, this became clear. > > A (somewhat bikesheeding, but this has been the vast majority of the posts on this thread anyway) note is that await could also be made to accept an iterable of futures, avoiding the use of Async\all combinators. > I considered this option — it looks nice with an array — but for some reason, it's not implemented in any language. And here's why. When you allow await to work with an array, it leads to significant complications. Because once you support arrays, you naturally want to add more variants, like: - await first - await any - await ignore and so on. And with additions like await until or await limit, it becomes a very large and complex statement. After exploring different options, I also came to the conclusion that using a function which returns a `Future` from parameters is more flexible and better than having a multitude of options. The only unresolved question is until, because it could be convenient. But it doesn’t exist in any other language.
