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