The Future of D Runtime

[Mathias Lang]

On Wednesday, 5 June 2024 at 23:58:14 UTC, Adam Wilson wrote:
>
> Before I get into the design of the DRT I want to propose rules 
> that will allow us to continue to evolve DRT in the future 
> without breaking past editions. [...]

We have to take into account the combinatorial explosion that 
comes with the `rename` method. For example, should you choose to 
change the `Throwable` interface (because it's old and really not 
good), you would need to make sure that everything that uses it 
is compatible with it. There are known ways to do it in other 
languages (https://wiki.qt.io/D-Pointer) but I think the rules 
you proposed are incomplete as they only work for functions, not 
types.

> For DRT I propose a sharded design with a split between the 
> compiler support modules and the universal system interface 
> shards. [...]

Layering things / encapsulating them is good, but you also need a 
way for inner layers to refer to outer layers, otherwise you 
severely limit the capabilities of your system.
Take for example unittests: we would like to provide a much 
better out-of-the box experience for unittests. You should get 
colors, summary, the ability to run them in parallel, or even a 
filewatcher that auto-recompiler them, out of the box. We *might* 
consider unittests to be in `Core`, but I'm sure the rest is not.

> Simple, so that we can move beyond the limitations imposed by 
> the C Runtime.

A resounding yes. Keeping the ability to easily bind to the 
CRuntime is useful (e.g. being able to spin up a socket and just 
look at the C documentation), but because it's "good enough", it 
was never good at all.