Second Draft: Coroutines

[Atila Neves]

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?