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