Thread overview
Second Draft: Coroutines
18 hours ago
Atila Neves
December 12

Stackless coroutines, is a way to enable asynchronous programming, for lesser skilled and less knowledgable people whilst offering efficient processing of events, safely.

This version of the proposal has been rewritten to account for a lack of understanding on the separation of library code versus what the language is offering.

And a few changes related to yielding. Yielding is no longer guaranteed to be implicit. You may explicitly yield using an await statement should you wish to. The library type must support implicit yielding if you wish to use it. Both may be used on the same type, it is entirely dependent upon the called methods attributes.

Lastly, the changes have been made to simplify the descriptor to make the implementation within the compiler a little bit easier. It does mean that you as a library author have no way to know about the functions in the state machine (not that you could have done much with them).

Current: https://gist.github.com/rikkimax/fe2578e1dfbf66346201fd191db4bdd4/649a5a6cc68c4bfe9f5a62f746a3a90f6b4beaf4

Latest: https://gist.github.com/rikkimax/fe2578e1dfbf66346201fd191db4bdd4

18 hours ago

On Thursday, 12 December 2024 at 10:36:50 UTC, Richard (Rikki) Andrew Cattermole wrote:

>

Stackless coroutines, is a way to enable asynchronous programming, for lesser skilled and less knowledgable people whilst offering efficient processing of events, safely.

This version of the proposal has been rewritten to account for a lack of understanding on the separation of library code versus what the language is offering.

And a few changes related to yielding. Yielding is no longer guaranteed to be implicit. You may explicitly yield using an await statement should you wish to. The library type must support implicit yielding if you wish to use it. Both may be used on the same type, it is entirely dependent upon the called methods attributes.

Lastly, the changes have been made to simplify the descriptor to make the implementation within the compiler a little bit easier. It does mean that you as a library author have no way to know about the functions in the state machine (not that you could have done much with them).

Current: https://gist.github.com/rikkimax/fe2578e1dfbf66346201fd191db4bdd4/649a5a6cc68c4bfe9f5a62f746a3a90f6b4beaf4

Latest: https://gist.github.com/rikkimax/fe2578e1dfbf66346201fd191db4bdd4

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

My main issue is that I don't think the DIP justifies the need for stackless coroutines (which I think are a good idea). It also seems more complicated than what other languages have, and I'm not sure why that is. Why @async return instead of yield? Why have to add @async to the grammar if it looks like an attribute?

17 hours ago
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