The Future of D Runtime

[Adam Wilson]

On Thursday, 6 June 2024 at 18:56:59 UTC, Mathias Lang wrote:
> 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.

I'm actually a fan of that approach for data structures, I've 
seen it referred to as either a `pImpl` for 
"Pointer-to-implementation" or a "Handle". Realistically, for 
editions this is likely the direction we need to go.

As for the combinatorial explosion problem. I'd rather have that 
than arbitrarily cutting off development of DRT. Yes, it will 
result in an ever increasing number of symbols. No way around 
that, in most cases we should be able to do redirections to newer 
code and leave the old methods as forwarding-stubs. Yes there 
will be cases where we can't But it doesn't have to be a 
geometric expansion.

>> 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.

IMO, the FileWatcher/Re-builder is something that I've always 
seen done outside of the compiler. The compiler compiles things, 
we need to avoid trying to make it the "Everything Program". I 
feel the same way about proposals that try to make the compiler 
responsible for dependency management for the same reason.

>> 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.

Agreed.