Second Draft: Coroutines

[Richard (Rikki) Andrew Cattermole]

On 14/01/2025 6:59 AM, Atila Neves wrote:
 > I had trouble understanding the proposal. If I didn't already know 
what a coroutine is, I wouldn't have found out by reading the abstract. 
There are a few sentences I didn't understand in their entirety either 
such as "If it causes an error, this error is guaranteed to be wrong in 
a multi-threaded application of it.".

I do not understand why you are having trouble with it.
It has not come up before and Gemini understood it.
It is short, precise and complete to what I mean.

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

As it currently stands this is not constructive feedback, there is 
nothing I can do with it. I do not understand what problems you are 
having with it.

> It also seems more complicated than what other languages have, and I'm 
> not sure why that is.

Its not more complicated, but I can understand that it may appear that way.

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

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.

None of which can be in druntime, has to be Phobos. But we cannot tie a 
language feature to Phobos, and if we do that I cannot experiment prior 
to PhobosV3 to ensure it both works as expected and to learn if any 
further expansion is needed.

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.

> Why |@async return| instead of |yield|?

Then ``yield`` would be a keyword, which in turn breaks code which is 
known to exist.

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

However there is a good question here, why not combine ``await`` 
statement with ``@async return``? Well the answer is you may want to 
return a coroutine, which couldn't be differentiated by the compiler.

> Why have to add |@async| to the grammar if it looks like an attribute?

All language attributes are in the grammar, there is nothing special 
going on there.

https://dlang.org/spec/grammar.html#attributes