D Editions

[Adam Wilson]

On Saturday, 1 June 2024 at 00:30:36 UTC, Gregor Mückl wrote:
> Defining things that way simplifies matters a lot.
>
> This brings me to a follow-up question: how can e.g. druntime 
> evolve in this framework? Its public interface (e.g. the object 
> class) needs to always stay compatible with *all* editions the 
> compiler supports at that time, right?

As we dig into Phobos 3 this is something that I’ve started to 
think about more. Realistically, I think the concept of entirely 
freezing DRT is simply not practical in the long term. Phobos is 
going to expand, and DRT will need to expand with it. I can only 
see pain and ruination if we box ourselves into freezing DRT.

Furthermore, before we can address the technical issues, I think 
we need to agree on whether DRT is part of the Compiler Editions 
or part of the Phobos Releases. I bring this up because the 
runtime sits in both camps, the Compiler hooks the runtime and 
the Library leverages the runtime to access system resources. I 
have a longer post that I am working on with my thoughts on what 
we’ll need to address specifically for Phobos 3+.

My inclination is to tie DRT to Phobos, and the reason is that 
*most* of what DRT does is provide access to system resources in 
a uniform manner for consumption by Phobos. Yes, DRT exposes 
compiler hook points, but that is a minor portion of what it 
provides. The bulk of the work that DRT does is in support of the 
Standard Library, so it should be tied to it.

Here are my thoughts on the rules for DRT. From an ABI 
standpoint, there are only three actions that can be taken: Add, 
Rename, Remove.
1. Remove: Banned. We cannot remove symbols from the DRT API. But 
we can rename them provided we follow the rename rules.
2. Rename: Renames include changing the parameters in any way. We 
can support this by offering either a shim that redirects to the 
new method or leaving the original method alone and building a 
new one next to it.
3. Add: The is probably the easiest. New symbols can be added at 
any time.

If we follow these rules then we can safely use the *latest* DRT 
version with all prior editions. Using the latest version of DRT 
means that we are free to ship critical fixes and ensure they get 
into the ecosystem as fast and as broadly as possible.