On Sun, Mar 04, 2012 at 03:34:26PM +1100, Daniel Murphy wrote: > "H. S. Teoh" <hst...@quickfur.ath.cx> wrote in message > news:mailman.372.1330833051.24984.digitalmar...@puremagic.com... [...] > > 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.
Hmph. Looks like there's no way to avoid massive overhaul? :-/ [...] > >> 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. But isn't this just a matter of overloading opIndex & friends? That's what I'm trying to do, at any rate. > >> 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. Well, I'm not afraid of redesign per se -- I consider AA's an important enough part of D to be worth the effort to do right. But I just wanted to know what I'm up against. :P > > 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. [...] I suppose I *could* add a function in aaA.d to throw the exception. Really ugly, but gets around needing an explicit dependency in object.di. I don't know which is worse though -- to make object.di depend on core.exception, or to make aaA.d depend on it. Both are in some ways circular dependencies. T -- Famous last words: I *think* this will work...