Which language constructs could be done as a library if we accept some breaking changes?

Ola Fosheim Grøstad ola.fosheim.grostad at gmail.com
Wed Dec 1 09:13:57 UTC 2021

On Tuesday, 30 November 2021 at 19:56:01 UTC, Guillaume Piolat 
> On Tuesday, 30 November 2021 at 14:46:59 UTC, Ola Fosheim 
> Grøstad wrote:
>> There should absolutely be an upgrade path
> Such as with -preview/-revert then?

This is possible:

1. -preview-d3-feature-X on the D2 side

2. -emulate-d2-feature-Y on the D3 side for common "deprecated" 

3. Allow subsystems compiled with both D2 and D3 to be combined 
using high level intermediate representation (HIR) so that you 
can transition one subsystem at a time from D2 to D3. Although, 
you might have to replicate some templates on both sides because 
I doubt that "static if" is suitable for HIR.

You have to decide case-by-case what is worthwhile. It has to be 
based on what existing code-authors find difficult.

>> For files ending in ".d" emulate most of the current 
>> behaviour. For files ending in ".d3" provide the full cleanup.
> Can you give an example of breaking changes that this .d3 trick 
> allows, that cannot be covered by -preview/-revert?

If you create a new modular frontend and follow a clean spec, 
then you will get many differences all at once. Anything that 
depends on "does-this-compile-traits" could break even if you try 
to emulate DMD. The alternative is to reimplement all quirks of 
the current frontend and that could have a negative complexity 
impact and a development time impact, basically not making it 

All changes that are cleaning up language semantics, can 
potentially break things such as traits. When you move something 
to a library or change things you will affect those that do 
"shoehorn tricks" with the language.

You should probably only aim for ease of transition for people 
who write good code. People who rely on trickery are very costly 
to support.

Anyway, «D3» is inevitable if the current compiler is difficult 
to evolve, maybe it already «exists» in the shape of another 
language with no affiliation to D.

More information about the Digitalmars-d mailing list