Re: PHP True Async RFC Stage 4

> It's vastly improved from the first version back in the spring, but there are still > numerous footguns Which specific footguns? $scope var? > Mainly, we should not be allowing anything but structured If you always follow the “nursery” rules, you always have to define a coroutine just to create a nursery, even when the coroutine itself isn’t actually needed. That’s why we end up with hacks like “Task.detached.” (*Swift*). And *Kotlin* keeps trying to invent workarounds. **TrueAsync RFC** takes a different approach and gives the programmer maximum flexibility while still complying with every principle of structured concurrency. At the same time, the programmer gains two styles of structured concurrency organization, one of which fully matches Trio. > I very much want to see it evolve further in that direction before a vote is called and > we're locked into a system with so many foot guns built in. Such an approach would require more changes to the code, and I don’t see how it would protect the programmer from mistakes any better than this RFC does. Of course, the with-style syntax would allow for maximum safety when working with tasks, but that’s not an issue with this RFC. The **Trio** model is not perfect; Kotlin and other languages do not adopt it (maybe by accident — or maybe not). It’s not suitable for all types of tasks, which is why the criticism is valid. Although Kotlin is criticized for storing Scope inside objects like: “Long-living CoroutineScope stored in objects almost always lead to resource leaks or forgotten jobs.” However, there is no other way to solve the problem when coroutines need to be launched within a Scope gradually rather than all at once. But... Ok... ```python async def background_manager(): async with trio.open_nursery() as nursery: while True: event = await get_next_event() nursery.start_soon(handle_event, event) ``` ^^^ The example of how the pursuit of an “ideal” ends up producing ugly code. My position is this: **TrueAsync** should support the best patterns for specific use cases while still remaining convenient for the majority of tasks. The fact that certain tools require careful handling applies to all programming languages. That doesn’t mean those tools shouldn’t exist.