> 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.
