http://d.puremagic.com/issues/show_bug.cgi?id=6658
--- Comment #9 from Iain Buclaw <[email protected]> 2013-04-02 02:45:00 PDT --- (In reply to comment #8) > DMD: > https://github.com/D-Programming-Language/dmd/blob/v2.062/src/e2ir.c#L2431 > > GDC: https://github.com/D-Programming-GDC/GDC/blob/master/gcc/d/d-elem.cc#L100 > > LDC: https://github.com/ldc-developers/ldc/blob/master/gen/arrays.cpp#L812 > > It's all reimplementations of the same thing. I guess there was a reason for > why the layer of abstraction was chosen to be this high, but in this situation > it's not doing anyone any favors. > When David first released gdc, the (In reply to comment #6) > (In reply to comment #5) > > I'd just like to say that statement is false. It wasn't a patch in the > > frontend, and no one but DMD benefits. > > Really?? > > We're talking about this, right? > https://github.com/D-Programming-Language/dmd/commit/c984175cf25dfa17b3956e8e33ff83547fa56b0a > > I thought GDC/LDC simply provided their own implementation of el_* and the > elem > type. When gdc was first released, it provided it's own implementation of dt* and the dt_t type. This is now what I widely regard of as a bad move. The DMD implementation of toobj.c; todt.c; typinf.c; has been getting further from GDC's copy of that part of the frontend, thus has become a pain to maintain upon each frontend update. Frankly I can never see it working trying to hack and wrap dmd backend calls into producing something that another backend see's as correct. So I'll be yanking those three files out of dfrontend/ sometime around this fall too. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
