Re: PHP True Async RFC Stage 4

On Tue, 14 Oct 2025, Edmond Dantes wrote: > > 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. > -- https://derickrethans.nl | https://xdebug.org | https://dram.io Author of Xdebug. Like it? Consider supporting me: https://xdebug.org/support mastodon: @derickr@phpc.social @xdebug@phpc.social