How to convert C to D using compiler?

Ola Fosheim Grøstad ola.fosheim.grostad at gmail.com
Thu Dec 9 00:19:19 UTC 2021


On Wednesday, 8 December 2021 at 21:04:36 UTC, Dennis wrote:
> Also true, I just think that being hyperbolically negative and 
> blaming the attitude of D's contributors is unfair.

I don't think anyone in particular is being blamed, but there is 
a mismatch between the chosen compiler architecture and an 
evolutionary development model. Evolution demands a more modular 
approach, and frankly, a constant reevaluation of the 
architecture with planned refactoring.

> That's not because the implementation of CTFE was abandoned 80% 
> through in favor of a new shiny feature, it's because there was 
> never a clear 100% to begin with, it's ever evolving.

That's probably true for a lot of things, also things like 
[inconsistencies and limitations of 
alias](https://forum.dlang.org/post/augmegssadjgrzvfhofk@forum.dlang.org) probably started as a quick add-on, but there is a limit to how far you can go with just evolution. If one keeps on evolving without redesigning then one ends up painting oneself into a corner where completion becomes an intractable proposition.

The most sensible thing then is to start remodelling into layers 
where you have a chance. The obvious starting point is to put a 
layer between frontend and backend. But then you have to make it 
a priority. Projects like ```@live``` and ```importC``` are 
rather ambitious. For importC you basically need to do like clang 
and implement [the commonly used gcc 
extensions](https://clang.llvm.org/docs/LanguageExtensions.html). 
Doing all of that at the same time pushes the finish-line far 
into the horizon. And then it is of limited use, even though a 
well developed ```@live``` analysis stage might be useful for 
analysing C-code and could possibly make some C-code accessible 
as ```@safe```.

Maybe D should do like C++ compilers and set up page with 
hatch-marks for feature completion. I don't start using next 
generation C++ or JavaScript without checking those feature 
tables for 100% completion.

For many contexts of serious software development having a 
half-baked feature is almost the same as not having it at all.



More information about the Digitalmars-d mailing list