Is it bad for object.di to depend on core.exception?

[H. S. Teoh]

On Sun, Mar 04, 2012 at 02:19:42PM +1100, Daniel Murphy wrote:
> "H. S. Teoh" <hsteoh at quickfur.ath.cx> wrote in message 
[...]
> > 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.

That makes sense.


> 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?


> 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?


> 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.)

I see.


> 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. :)

The question still stands, though, is there a reason for core.stdc.stdio
to be compiled without the include path to druntime/src?


T

-- 
All men are mortal. Socrates is mortal. Therefore all men are Socrates.