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