Second Draft: Coroutines

[Mai Lapyst]

On Friday, 31 January 2025 at 16:12:43 UTC, Richard (Rikki) 
Andrew Cattermole wrote:
> Perma: 
> https://gist.github.com/rikkimax/fe2578e1dfbf66346201fd191db4bdd4/7bba547fb6ea09deb2f0cfda2d852c409ace0142

There's still no writing about `opConstructCo`. Maybe a bit of 
background will help you. I'm in the process of writing an own 
frontend for the dlang language, and for me as an sudden 
implementor of the language, I find myself inside a unique spot 
for interacting wich such feature requests.

Like I said; you explaint that only `opConstructCo` is the method 
/ function that should be called to construct coroutines by the 
AST lowering, even called it a "new operator", but you still 
failed to include it in the section for changes to the language 
documentation. While it's correct that it's not needed for the 
grammar section, it is described in an text with starts with "a 
*potential* shell" telling me as a implementor that this is 
**not** required while infact it is; just like you said: its an 
new operator, so it should be clearly marked as such. Maybe in a 
new section after the grammar changes, or wherever, as long as 
it's more clearly that it is required as you yourself said:

> It is not part of the DIP. Without the operator overload 
> example, it wouldn't be understood.
> ....
> The operator overload ``opConstructCo`` is part of the DIP.
> Therefore there are examples for it.

So it is part of the DIP! Please state it so without adding 
"potential" or "purpose of examples only" before the **only 
occurence** of it inside the whole document.

Maybe a change like this:
```
# Implementation

...

Implementors also need to be aware of the new `opConstructCo` 
operator which is used as an way to morph coroutine objects into 
library understandable types.
```
Or something similar.

> D classes are a great example of this, forcing you to use the 
> root class ``Object``, and hit issues with attributes, monitor 
> ext.

I understand the sentiment behind it, and I agree that forcing 
the wrong things can be unproductive. But then again, it's an 
language, even requiring the spelling of an attribute is forcing 
the hand of programmers, so one or more types in `core`, will not 
be much of a difference. I only fear that introducing such a 
complicated technique will lead to either more fractation of the 
community and/or vendor log-in for the only library that will 
araise out of this, leading to more problems of root classes like 
``Object`` that everyone finds unfortunate but is not willing 
enough to go head-to-head with said library to make things better.

It's also a concern about people new to the language; it's still 
hard as it is to get into dlang with it many pitfalls, not only 
that classes are GC'd, but also things like postblitting which 
completly work differnetly than any other language and makes 
seemingly local created instances suddenly globally shared 
between the parent instances. My fear is that introducing a 
non-easy to understand way of using asyncronous functions will 
lead to incompatible libraries that throw errors nobody quite 
understands, epsc beginners that will drive them out of the room 
entirely they're not even halfway in.

But it will remain to be seen what the future holds. Like you 
said, it's atleast able to morph into the other provided 
solutions, so for the start any knowledgeable enough person can 
write their abstraction ontop of it to get started using dlang's 
coroutines and we'll see how it all plays out.