Asynchronous functions

solidstate1991 laszloszeremi at outlook.com
Tue Jul 1 10:15:51 UTC 2025


Basically it would give D some built-in multithreading support, 
by moving some of it to the runtime, and would make our language 
more on-par with competitors. Would likely need its own support 
from the compiler.

I would either add the keyword `asynchronous` to mark such 
functions, or `@async`, I think a prior research on which would 
break less code would be needed.

Key concepts:
- No return values, or return values are for special purposes 
only (an exception or error code, etc.). However, when called, 
still returns a struct consisting of the thread ID and maybe the 
pointer to a potential status code and/or exception.
- Writing to memory that outlives the thread is still possible, 
and is the programmer's duty to ensure no unwanted effects, for 
which D's own tools, such as memory safety and thread safety 
(`pure`, `shared`, etc.) can be used of course, alongside with 
potential library enhancements. Alternatively normal asynchronous 
functions could be always pure, etc., with an alternative keyword 
to opt-out from such feature (`@__gasync`?).
- Any asynchronous function marked with `@nogc` should be spawned 
as a low-level thread, outside of garbage collection, which would 
enable real-time applications.

Further enhancement could be adding language support for fibers 
in a similar way.


More information about the dip.ideas mailing list