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