"H. S. Teoh" <[email protected]> wrote in message news:[email protected]... >> Then, a few of years ago they were moved into druntime, so that the >> implementation and interface could be improved without modifying the >> compiler. > > Is that when struct AssociativeArray came into being? I'm still trying > to understand how exactly AssociativeArray is connected with the C > linkage implementation. Is the compiler "aware" of AssociativeArray at > all? How does it work when you declare, say, int[string] and try to make > a range out of it? >
Yeah. The compiler is aware of AssociativeArray in that it gags semantic errors on it, and turns V[K] types into AssociativeArray!(K,V) types in some cases (like for member lookup). It's sortof messy, try grepping for getImpl in dmd. > >> While only about three things were ever added to the AA interface, >> this had the major side effect of introducing dozens of ice bugs and >> _increasing_ the amount of code needed to support AAs, especially in >> the interpreter and the glue layer. On top of this, most of the >> functionality is still done with the compiler emitting druntime calls. > > And what are the issues preventing the compiler from *not* emitting > these calls? > Well, for example: aa[k] = v; becomes *__d_aaGet(&aa, k, k.typeinfo) = v; // or something like this And iirc there is no way to currently do this through AssociativeArray. > >> We're basically stuck with this until someone comes up with a solution >> that lets everything work as it should, with AAs completely in the >> runtime or the compiler. > [...] > > Heh. I just try to fix a few AA bugs and now I've to rewrite the thing > from scratch? Let me think a bit more about that one. :) > This is basically the conclusion I've come to when I've tried to fix AA bugs and run into these problems. Patch the holes (and make things worse) or do a full redesign... neither have really inspired me to spend lots of time working on it. > The question still stands, though, is there a reason for core.stdc.stdio > to be compiled without the include path to druntime/src? I doubt it, though it's probably not desirable to make object.d import anything else. Is there an extern c function you could call that would throw the range error for you? If you make a pull request the people who maintain druntime will look though it.
