On Wednesday, April 11, 2018 09:23:29 Kagamin via Digitalmars-d-announce 
> On Monday, 9 April 2018 at 19:36:23 UTC, Atila Neves wrote:
> > If you add to all that "No, really, it's ok, there's this
> > project that forked one of the compilers. No, it's not the
> > reference compiler. There's just this bit of non-standard
> > syntax to learn that's neither C nor D", then the chances of
> > convincing any "normal" engineer are 0.
> It is the reference compiler though (which is the frontend), the
> backend is different, but they don't want the dmc backend do
> they? Also recently it started to use pragma and import syntax,
> which are both D.

Yes, the frontend is shared, but you don't just use the frontend. You use
the whole compiler. dmd is the reference compiler and what your average
programmer coming to D is going to expect to be using (at least initially).
And telling folks that they have to use a language feature that is not
supported by the reference compiler is not going to go over well with a lot
of people. It would be one thing to tell them that they should use ldc,
because it generates faster code. That doesn't involve forking the language.
Your code would then still work just fine with dmd. It would just be slower.
It's quite another thing to tell them to use a feature that dmd doesn't
support. That _would_ be forking the language, and it would mean writing
programs that would not work with the reference compiler. Many folks are not
going to be happy with the idea of using a fork rather than the real deal.
Some folks will probably be fine with it, but in general, it just plain
looks bad.

It's one thing for someone who is familiar with D to weigh the options and
decide that being tied to ldc is okay. It's quite another to tell someone
who isn't familiar with D that in order to use D, they have to use a feature
which only works with a specific compiler that is not the reference compiler
and which will likely never work with the reference compiler.

- Jonathan M Davis

Reply via email to