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
Tue Nov 30 14:46:59 UTC 2021


On Tuesday, 30 November 2021 at 13:49:12 UTC, Guillaume Piolat 
wrote:
> On Sunday, 28 November 2021 at 20:47:28 UTC, Ola Fosheim 
> Grøstad wrote:
>> If there was a majority in favour of D3, with breaking 
>> changes, and a strong focus on meta-programming, then it would 
>> make a lot of sense to streamline the language.
>
> I just don't understand the premise of a "D3".
> We don't need "D3" to have breaking changes, we now have a 
> **better** system with -preview/-revert.
>
> Considering D2 approximately halved the userbase, talks about 
> "D3" should really be talks about new -preview flags. The idea 
> that a magical breaking change  fixes the langage without a 
> nice upgrade path is magical thinking, because it would be 
> strictly **worse** than what we have today.

There should absolutely be an upgrade path, which is why "equally 
expressive" would be very much a requirement. I believe to a 
large extent that one could do it this way:

For files ending in ".d" emulate most of the current behaviour. 
For files ending in ".d3" provide the full cleanup. Then you can 
combine ".d" and ".d3" files. Much like how you combine ".c", 
".cpp", ".mm" files in X-Code for C, C++, Objective-C.

One possible way to arrive at this path would be to create a high 
level IR (HIR) for the current DMD compiler, then a new D3 
compiler would emit the same high level IR and you would combine 
the HIR output using a high level linker (basically a compiler). 
You could do the same for C too.

The problem right now is that there is neither LTS or a compiler 
code base that is suitable for further evolution, so with no 
change on the technological level you effectively "halve the 
population" anyway by slow evolution. There are other languages 
quite close to D in semantics, so without "D3" there are other 
languages that take that role regardless.

It also makes absolutely no sense to write a new compiler 
codebase that emulate the quirks of dmd?

The better strategy is to have:

1. DMD -> HIR
2. D3 -> HIR
3. HIR -> LLVM

That allows you to give DMD D2 long term support and also improve 
on compilation speed and backend support (ARC and borrowing) for 
both.



More information about the Digitalmars-d mailing list