my d blog has idea of effect system to replace @nogc etc

[Adam D Ruppe]

On Monday, 15 August 2022 at 16:16:35 UTC, Sönke Ludwig wrote:
> The most prominent example would be something like vibe.d's 
> `@blocking`, which currently just acts as documentation, but 
> would be really useful if something like `@nonblocking` could 
> actually be enforced at compile time - currently there is just 
> a runtime solution for that.

Aye, async in general has a lot of uses of this kind of thing. In 
addition to just not hogging the worker thread, being responsive 
to a cancellation request is a nice thing.

Speaking of blocking, one of the effects I'd envision is 
something like "loops". Something blocking on a loop can more 
harmful to the event-driven i/o model than other blocks - at 
least other blocking calls can be interrupted by signals or 
something.

On the one hand, you might think of it as madness to say 
`denies_effect!loops`. How will you get any work done? But 
there's two interesting bits: 1) you might be able to define it 
with higher order functions and 2) D's `foreach` loop is special.

See, a foreach loop can just by syntax sugar over an opApply 
function call.... and we could say one of those loops instead 
just has the effects of opApply (which would necessarily add the 
effects of the user-provided delegate, of course).

So you could imagine an opApply that uses the hidden effects 
escape to implement a loop, but inserts its own periodic 
`if(yield() == CANCEL) return;` logic, providing both regular 
returns to the scheduler event loop and opportunities to cancel 
the task. Indeed, the work chunks may even be auto-parallelized 
in the process too.

Of course, users could also use the trusted hidden effect, but 
the act of doing so at least reminds them that they ought to be 
careful.