> That contradiction encourages people to wrap it to “make it awaitable,” which > re-introduces the very problem you’re trying to avoid.
Hm... > Renaming it to something like joinAll() or joinAfterCancellation() keeps the > semantics intact while communicating the intent: this isn’t a future; it’s a > container join. > That small change would make the interface self-documenting and harder to > misuse. There’s also an issue with the method name. The `awaitCompletion` method waits not for the Scope to close, but for all tasks to complete. That’s not the same thing. Maybe `joinAll` really is better, since it resembles the way threads are expected to work? But does `joinAll` fully reflect the meaning? After all, it’s not about waiting for *all* tasks in general, but only for those that exist while the function is active. That’s a very important distinction. Because in addition to this function, there could also be something like `awaitFinally` or similar. > That's what we are here to do, no? Discussion is useful if it makes things > better than the sum of their parts. Typically, when developers start medium or large projects, they begin with the key components intentionally leaving out details that can be easily changed later. There’s definitely something to discuss here, but is it really worth doing it *right now*? :) > // Looks innocent, but this can wait on foreign work: > $scope->awaitCompletion(Async\timeout(60000)); // rename -> joinAll(...)? If the developer wanted to start a task and limit its execution time, the code looks fine. And I would add a `try/catch` to handle errors. > My point is that it wasn't listed in "future scope" of the RFC, though > they're mentioned throughout the document, in passing. Yes, that was done intentionally on the advice of the PHP Team.
