On Saturday, �� December 2011 at 05:48:18 UTC, dolive wrote:
Why do need to re-create a new compiler not participate in the
maintenance ddmd ?
What better features than ddmd ?
I assume you are comparing SDC and DDMD on the basis that they're
both written in D. While being written in D is a main point for
SDC, it's not the only one.
SDC is written from scratch with no other dependency than LLVM.
Like LDC, it uses LLVM for the back-end, but unlike LDC, it
doesn't use the DMD front-end.
GDC and LDC inherit all the advantages and disadvantages of the
DMD front-end. They get the whole language, or at least as far as
the reference compiler implements it, up front. But they also get
all the baggage of DMD: bugs, legacy code, etc. The SDC front-end
is written with only D2 in mind and inherits no code from any C++
or D1 compiler, while DMD was built incrementally while D was a
moving target. Due to all of this, the design of the codebase is
fundamentally different from DMD.
On the other hand, DDMD is a massive project in its own right.
First you have to convert all of DMD's sources to D, then you can
get onto the real task: turning the new code into idiomatic D
instead of "C++ with a D compiler". And you have to keep it up to
date with DMD development until DDMD is ready to take over.
It's not yet clear which approach is "better", only time will
tell. But the SDC project has already reaped benefits from its
approach, and the design allows for many improvements as the
project moves forward.
Do note that as an SDC dev, I do have a bias in this comparison,
but feel free to come up with some actual arguments for DDMD :)
