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