Yes. D's design is based around the idea that semantically valid C will compile in D (apart from crud like function pointer syntax etc.) but there are tools to convert C to D (As used in the dmd compiler backend (which dates back to the 80s I believe, but is now in a tasty form of spaghetti D)

> D's design is based around the idea that semantically valid C will compile in D

AFAIK it's that code which compiles in both c and d should have the same behaviour; not that c code should necessarily compile in d. Examples of c that don't work in d are trivial.

> there are tools to convert C to D (As used in the dmd compiler backend (which dates back to the 80s I believe, but is now in a tasty form of spaghetti D)

Dmd's backend was ported by hand. What tools are those? I know there are tools to convert header files, but I don't know of any that actually convert code.

> Dmd's backend was ported by hand.

Not quite, the c++ source was massaged to be free of weird corner cases of the grammar and preprocessor (e.g. enforcing no spaces between '#' and the preprocessor keyword) and then a tool called magicport was used to convert the frontend in one shot. The backend was mostly converted by "hand" (i.e. grep after some more massaging).

There are several tools to translate headers though dstep[1] and dpp[2] come to mind

[1]: https://github.com/jacob-carlborg/dstep [2]: https://github.com/atilaneves/dpp

Magicport was used to convert the front end. The back end was done by hand, one file at a time (and passing the test suite after each file).

Most of the conversion was "replace -> with ." and then fixing whatever the compiler complained about.

Semantically valid as in valid D, not valid C.

> Dmd's backend was ported by hand

I stand corrected then. Visual D has one cpp2d built in, which I assumed was used

> the dmd compiler backend (which dates back to the 80s I believe,

You'd be right!

> but is now in a tasty form of spaghetti D)

Haha. It's still as awful as the C code it was manually converted to D from. I've been slowly improving it bit by bit.

Could you write(apologies if I'm missing something) some documentation on how the backend is organised and the overall motion through it? I've often looked at it but been almost totally unable to grok how any thing actually works beyond the abstract of what the optimisations say on tin.

Could a step forward be to start afresh and then call into the old backend stages but ultimately rewrite them in more bearable code where possible? Might be a compile time trade-off there, to an extent.

If you're really into it, the most straightforward way is to simply scan the code files one by one.