Second Draft: Coroutines

[Richard (Rikki) Andrew Cattermole]

On 24/01/2025 10:17 AM, Sebastiaan Koppe wrote:
> On Thursday, 23 January 2025 at 20:37:59 UTC, Richard (Rikki) Andrew 
> Cattermole wrote:
>>
>> On 24/01/2025 9:12 AM, Sebastiaan Koppe wrote:
>>> Upon yielding a coroutine, say a socket read, you'll want to park the 
>>> coroutine until the socket read has completed. This requires a signal 
>>> on completion of the async operation to the execution context to 
>>> resume the coroutine.
>>
>> Right, I handle this as part of my scheduler and worker pool.
>>
>> The language has no knowledge, nor need to know any of this which is 
>> why it is not in the DIP.
> 
> Without having a notion on how this might work I can't reasonably 
> comment on this DIP.
> 
>> How scheduling works, can only lead to confusion if it is described in 
>> a language only proposal (I've had Walter attach on to such 
>> descriptions in the past and was not helpful).
> 
> You don't need to describe how scheduling works, just the mechanism by 
> which a scheduler gets notified when a coroutine is ready for resumption.
> 
> Rust has a Waker, C++ has the await_suspend function, etc.

Are you wanting this snippet?

```d
// if any dependents unblock them and schedule their execution.
void onComplete(GenericCoroutine);

// Depender depends upon dependency, when dependency has value or 
completes unblock depender.
// May need to handle dependency for scheduling.
void seeDependency(GenericCoroutine dependency, GenericCoroutine depender);

// Reschedule coroutine for execution
void reschedule(GenericCoroutine);

void execute(COState)(GenericCoroutine us, COState* coState) {
     if (coState.tag >= 0) {
         coState.execute();

         coState.waitingOnCoroutine.match{
             (:None) {};

             (GenericCoroutine dependency) {
                 seeDependency(dependency, us);
             };

             // Others? Future's ext.
         };
     }

     if (coState.tag < 0)
         onComplete(us);
     else
         reschedule(us);
}
```

Where ``COState`` is the generated struct as per Description -> State 
heading.

Where ``GenericCoroutine`` is the parent struct to ``Future`` as 
described by the DIP, that is not templated.

Due to this depending on sumtypes I can't put it in as-is.

Every library will do this a bit differently, but it does give the 
general idea of it. For example you could return the dependency and have 
it immediately executed rather than let the scheduler handle it.