D Editions

Dukc ajieskola at gmail.com
Sun Jun 2 09:38:54 UTC 2024


Adam Wilson kirjoitti 1.6.2024 klo 7.31:
 >
 > 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.
 >
 > [snip]
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 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.

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.

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.


More information about the dip.ideas mailing list