Second Draft: Coroutines

[Atila Neves]

On Monday, 13 January 2025 at 18:51:27 UTC, Richard (Rikki) 
Andrew Cattermole wrote:
> On 14/01/2025 6:59 AM, Atila Neves wrote:
> > I had trouble understanding the proposal. If I didn't already

> I do not understand why you are having trouble with it.
> It has not come up before and Gemini understood it.

I haven't read it before; I'm also not an LLM.

> It is short, precise and complete to what I mean.

I don't think that's the case.

> If you want me to change it, I need a lot more feedback 
> including:
>
> - How you are interpreting it
> - What questions you had after reading it
> - what did you expect it to contain

Sure. I think the feedback would be quite long, though.

I wonder if it would be better to have a coroutine library first; 
I know that it would be a lot more clumsy to use than it would be 
with language support. But maybe having a library prove itself 
useful first would be the way forward.

> Other languages can tie the feature to a specific library, 
> which will not work for us.

Why is that?

> Consider why we cannot: a coroutine language feature is tied to 
> its representation in library, which is tied to is eventloop, 
> which is tied to sockets, windowing, pipes, processes, thread 
> pool ext.

How is this different in other languages?

> None of which can be in druntime, has to be Phobos.

Why is that?

> Also coroutines are used in both generative and event handling 
> basis, they are not the same library wise. Tieing it to just 
> one is going to be hell for someone. Most likely me as I'm 
> responsible for the user experience.

Again, how is this different in other languages?

>> Why |@async return| instead of |yield|?
>
> Then ``yield`` would be a keyword, which in turn breaks code 
> which is known to exist.

C++ got around that with `co_yield`.

> There is no benefit to doing this. But we _could_ do it.

Familiarity would be a benefit.

> All language attributes are in the grammar, there is nothing 
> special going on there.
>
> https://dlang.org/spec/grammar.html#attributes

For historical reasons, yes. I'm aware one can't attach an 
attribute to `return` otherwise right now, but wherever they 
already work I would argue that `core.attributes` is the way to 
go.