D is our last hope

[Siarhei Siamashka]

On Wednesday, 20 December 2023 at 15:17:46 UTC, Richard (Rikki) 
Andrew Cattermole wrote:
> On 21/12/2023 4:12 AM, Siarhei Siamashka wrote:
>> 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.
>
> The development of dmd is already limited!

Yes, of course it's limited! That's precisely what we are 
discussing here. See 
https://forum.dlang.org/post/htrjpzxubkbujxbcjnfd@forum.dlang.org 
where it started ("seriously, figure out a way to dogfood Phobos, 
it's insane that the premier project in the language refuses to 
use its stdlib"). And this is a practical problem. Here's how 
DMD's backend code looks today: 
https://github.com/dlang/dmd/blob/v2.106.0/compiler/src/dmd/backend/elfobj.d

Let's suppose that I want to work on fixing 
https://issues.dlang.org/show_bug.cgi?id=24286
I would like to add a bunch of debugging prints at the right 
places to get a better picture about what's going on there. What 
do I have at my disposal? Yeah, only "printf" from the standard C 
library. Why? Because reasons.

```D
import std.stdio, core.stdc.stdio;

alias Elf64_Addr   = ulong;
alias Elf64_Xword  = ulong;
alias Elf64_Word   = uint;
alias Elf64_Half   = ushort;

struct Elf64_Sym
{
     Elf64_Word  st_name;
     ubyte       st_info;
     ubyte       st_other;
     Elf64_Half  st_shndx;
     Elf64_Addr  st_value;
     Elf64_Xword st_size;
}

void some_function(Elf64_Sym *s) {
     // Nah, we can't do this for debugging prints in the DMD 
backend code
     writefln("some_function: s = %s", *s);

     // The true way! Isn't this beautiful? Don't even dare to 
complain.
     printf("some_function: s = Elf64_Sym(%d, %d, %d, %d, %ld, 
%ld)\n",
         s.st_name, s.st_info, s.st_other, s.st_shndx, s.st_value, 
s.st_size);
}

void main() {
     auto s = Elf64_Sym(1, 2, 3, 4, 5, 6);
     some_function(&s);
}
```

The reliance on a restricted subset of D is annoying and inhibits 
productivity. And apparently you even want to cement this 
unfortunate status quo by introducing a transpiler from this 
"worseD" to C++. I see only troubles and no benefits at all.

> It has to communicate with C++ for ldc and gdc to work today.

Are you saying that using Phobos would prohibit interoperability 
with C++?

> It was ported mechanically from C++.
>
> It works without druntime being linked in (with optional 
> support for GC clean up -lowmem switch).

Is this really desired? Should it really work this way?

> The barriers you think exist don't, due to historical reasons.

?