D Editions

[Adam Wilson]

On Sunday, 2 June 2024 at 09:38:54 UTC, Dukc wrote:
> Yes, I agree this is something we need to decide. I also agree 
> that locking DRuntime API isn't a good idea.
>
> But, I think it should be updated with the compiler, not with 
> Phobos. DRuntime is essentially language API that is called 
> without special langauge syntax.

I'm writing a longer post on this subject. But the TL;DR is that 
this view is factually incorrect and is based on an 
misunderstanding of what DRT is to the ecosystem. Only a tiny 
fraction of DRT today deals with the compiler (as an API for 
language). The vast majority of DRT is providing system resources 
to Phobos. Given that the library-system interface is only going 
to continue to grow, logic would dictate that tying DRT to the 
library is the only practical choice. Tying DRT to the compiler 
forces Phobos to wait for the latest edition to use the latest 
DRT, which makes no sense given that the vast majority of the 
work is on the system-interface components and not the 
compiler-interface.

Fun historical note, DRT began as a system-interface library for 
Tango and only later was it used as a convenient place to put 
compiler hooks. The commonly held view that DRT primarily exists 
to serve the compiler is a fascinating confirmation that we've 
moved past the Tango/Phobos split though.

> I think what edition DRuntime uses internally is it's own 
> implementation detail. We should design it so it works with all 
> editions on the client side - just like any widely used library 
> will want to do.

Technically yes, but in practice, because we can mix-match 
editions, DRT will always need to support the latest edition. 
 From a practical standpoint you always need to be using the most 
recent edition that the user code is compiled to, and since 
Editions are being built as "latest edition by default" that 
means that by default the latest Runtime and Libraries are going 
to be used. So might as well just support the latest.

> There will probably be times when we want to change behaviour 
> based on what edition client code uses. I suggest adding a 
> special token for that, `__EDITION__`. A DRuntime function, (or 
> any D function, really), can use that as a default parameter to 
> figure out what edition the client is using, just like 
> `__FILE__` and `__LINE__` can be used as default parameters for 
> debugging functions. We can use that trick to deprecate old 
> functions.

IMO, special tokens are always a horrible solution. In this case 
because it does not fully solve any of the three ABI scenarios I 
listed. You still have to follow the Rename rules the moment you 
need to change the parameter list in any way. All the special 
token does is allow you to branch on different editions when the 
code has internal changes, so it solves arguably the least 
important subset of Edition related problems. Furthermore, once 
you are forced to change the parameter list you've now create a 
small number of methods that each contain an opaque number of 
Edition implementations, which means the consumer now has to 
mentally juggle which API contains which edition they need.

> Given any particular edition X, a DRuntime function should be 
> supported indefinitely, but when changing editions in the 
> client module, DRuntime calls may also need revision. This also 
> lets code to call DRuntime functions from other editions if 
> they really want to, which I see as a good thing. This also 
> means Phobos will have easy time using it, since it can pick 
> it's own edition for it's modules and DRuntime will support 
> that to matter the compiler version.

Agreed. When designing for the long-term there are very few 
practical ways to do it, which is why I laid out the process that 
I did. It's a well established way of handling this problem. We 
know it works.