D is our last hope

[Siarhei Siamashka]

On Wednesday, 20 December 2023 at 03:49:30 UTC, Richard (Rikki) 
Andrew Cattermole wrote:
> On 20/12/2023 4:21 PM, Siarhei Siamashka wrote:
>>     We currently have a chain of compilers if you want to 
>> bootstrap
>>     latest compiler from C++.
>> 
>> This doesn't look good.
>
> This is why its N compilers.

 From where I stand, it looks like someone tried to tweak the GC 
and memory allocation in a non-portable ubeRc0ol way inside of 
the DMD source code. Which made it incompatible with GDC 11, but 
who cares? Supposedly this is intended to make the compiler 
faster. Yet the DMD compiler falls flat on its face due to 
mundane reasons in a simple compilation speed dependent 
benchmark: 
https://forum.dlang.org/thread/fqziujkpdbivsqxsgszu@forum.dlang.org

> Every link in that chain of compilers has to be maintained.

My alternative mundane suggestion would be to just fix the DMD 
code on github, so that it can be compiled with GDC 11 again. And 
then add GDC 11 to the CI in order to prevent it from breaking 
again in the future.

> Its not just a matter of maintaining the frontend, but also the 
> glue code per version of the backend you target.
>
> Plus druntime and phobos for good measure.

GDC 11 includes both druntime and phobos. There's no need to have 
the glue code per version of the backend as long as GDC is 
maintained as a part of GCC.

Again, my suggestion is to take the C++ implementation of the D 
frontend from GDC 11. Rebrand it into "D language 2017 edition" 
and add it back to the mainline GCC. Treat this frontend as a 
separate programming language and maintain it independently from 
the "modern D" frontend. But if the community is not interested 
in a properly maintained "2017 edition" of D language, then this 
idea is naturally dead.

> Oh and GCC has rules around what compilers may be used to 
> compile GCC for distribution. So if D isn't already on a given 
> target... have fun with that.

Could you please clarify this statement?

> On the other hand our frontend is already marked up with 
> ``extern(C++)``, and has manually maintained C++ headers for it.
>
> If only we could take advantage of that.

So now some sort of an ubeRc0ol transpiler from D to C++ is a 
magic solution?