On Wednesday, April 11, 2018 09:23:29 Kagamin via Digitalmars-d-announce wrote: > 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