D is our last hope

[Siarhei Siamashka]

On Wednesday, 20 December 2023 at 14:01:00 UTC, Richard (Rikki) 
Andrew Cattermole wrote:
> From what Iain has said that I remember, you can only use the 
> last 3 major versions in binary form to compile the next 
> version. They are pretty strict.

Yes, if somebody is contributing a patch for GCC 14, then they 
can't immediately rely on a newly added fancy GCC 13 feature, but 
have to ensure that the code still can be successfully compiled 
by GCC 11, GCC 12 and GCC 13. Even older versions may or may not 
work, but this is not guaranteed.

GDC 15 won't have an obligation to be compilable by GDC 11. But 
this doesn't mean that GDC 15 (or DMD) suddenly needs to 
intentionally break compatibility with GDC 11.

>> So now some sort of an ubeRc0ol transpiler from D to C++ is a 
>> magic solution?
>
> We already have it for generating headers.
>
> ```
>   -HCd=<directory>  write C++ 'header' file to directory
>   -HCf=<filename>   write C++ 'header' file to filename
> ```
>
> It is incomplete, but there is enough there to see that it is 
> in fact possible to do what I am suggesting and has quite 
> desirable use cases outside of compilers.
>
> This isn't a far fetched idea. It already exists.

GDC 11 can successfully compile the following code:

```D
import std.stdio, std.string, std.range, std.algorithm, std.conv;
void main() @safe {
   "1, 2, 3, 4, 5".splitter(',').map!(x => 
x.strip.to!int).sum.writeln;
}
```

Can a hypothetical D to C++ transpiler do the same?

I don't suggest to rewrite the DMD compiler code in this style, 
but introducing a transpiler would force DMD developers to be 
limited to some sort of a "worseD" subset of the D language. Also 
the transpiler itself is an extra weak link and a potential 
source of bugs.