"H. S. Teoh" <[email protected]> wrote in message news:[email protected]... > So I'm still working on fixing issue 5030, which *should* have been a > trivial fix. But I'm running into a bunch of circumstantial problems, > among which is this new method in AssociativeArray(Key,Value): > > Value opIndex(Key key, string file=__FILE__, size_t line=__LINE__) > { > auto p = key in *cast(Value[Key]*)(&p); > if (p) return *p; > throw new RangeError(file, line); > } > > Originally it was simply Value opIndex(Key key) without any range check, > which is probably a bad idea, so I added the throw RangeError in there. > > However, this introduces a dependency from object.di to core.exception. > So this requires import core.exception in object.di, without which > Phobos doesn't compile (for obvious reasons). But adding the import > causes druntime to fail to compile, because, for example, > core.stdc.stdio is compiled withouth druntime/src in the compiler's > search path, so the compiler can't find core.exception. > > So I'm wondering, is it OK to add druntime/src to the compiler's search > path when building druntime? Or is there a reason for the omission? > > But perhaps a more pertinent question is, why is there so much > duplication between aaA.d and object.AssociativeArray? For example, > object.AssociativeArray basically copies (with modifications!) a bunch > of implementation-dependent details from aaA.d, and sometimes uses that, > and sometimes uses the other. Is it possible to dispense with this > schizophrenic code duplication (which is very fragile, since changing > the AA implementation in aaA.d will almost certainly break the Range > stuff in AssociativeArray)? >
Ok, let me tell you a story. Once apon a time AAs were part of the language proper, doing anything with them resulted in calls to druntime c linkage functions, which you can see in aaA.d. Then, a few of years ago they were moved into druntime, so that the implementation and interface could be improved without modifying the compiler. 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. In the last release, Andrei made things worse by copying the AA implementation layout into object.di in order to make ranges work. (To be fair there isn't really a better way to do this with the current setup.) 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.
