Language editions
Timon Gehr
timon.gehr at gmx.ch
Sat Oct 7 19:34:03 UTC 2023
On 10/7/23 20:49, IchorDev wrote:
> I haven’t seen anyone mention this yet…
>
> https://github.com/dlang/DIPs/pull/234#issuecomment-1751054587
>
> This is exciting, but also a bit worrying.
>
> I’m never going to be able to reasonably support multiple editions of
> the language at once, so I’d likely always support the newest one. I’m
> worried that this change might fracture D’s library developers.
The intention is the opposite. The vision is actually that library
authors only have to support one edition of the language at a time. Code
written for different editions can interoperate in the same compiler
invocation as they will be based on a compatible internal AST
representation.
So basically, everyone updates (or does not update) their editions at
their own schedule and old code keeps working. In particular, libraries
written for older editions can be seamlessly used with new code written
in the latest and shiniest edition. It is a bit like feature flags, but
they are enabled per source file instead of per compiler invocation.
Another analogy is that it is like ImportC, but instead of importing C
code, you import code from another D edition.
This allows editions to freely introduce breaking language changes
without breaking the ecosystem at all.
There will be much less pressure on library authors to keep their
libraries up to date with the latest language changes.
In practice, of course I anticipate there being some leftover friction,
for example, there will certainly be some bugs (or regressions due to
bug fixes) and limitations that only affect some combinations of
editions, but overall I think both library authors and compiler
writers/language designers will be in a much better place than before.
More information about the Digitalmars-d
mailing list