> Would it be better to instead of having ->awaitCompletion (which feels like > an implicit implementation of Awaitable without an explicit implmentation -- > which is the part that was bothering me), maybe having something like > ->joinAll() or ->joinOnCancellation()? > That way someone like me won't come along and wrap them in an Awaitable > because it looks Awaitable.
For example, you have an interface `DataBaseAdmin` with a `removeDB()` method and a class that implements it. You need to be able to delete the database, but with an additional condition. So you create a decorator class with a method `ContextualDBAdmin::removeDBWhen($extraRules)`. As a result, the decorator class is logically associated with the `DataBaseAdmin` interface. The question is: **so what?** > It also might be a good idea to make specifying a timeout in ms mandatory, > instead of a taking an Awaitable/Cancellation. The idea is correct, but there will definitely be someone who says they need more flexibility. And it's true you can create a `DeferredCancellation` and forget to finish it. :) There are a lot of such subtle points, and they can be discussed endlessly. But I wouldn’t spend time on them. > It also might be good to provide a realistic looking example showing a "bad > case" of how this is dangerous instead of simply saying that it is, showing > how a scope is not a 'future', > but a container, and preemptively mention TaskGroups, linking to the future > scope (which it should also probably be listed there as well). 1. It’s very difficult to write a realistic example that’s still small. 2. The `TaskGroup` or `CoroutineGroup` class is left for future discussion. In the final documentation, it will be exactly as you suggested.
