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

Daniel Murphy yebblies at nospamgmail.com
Sat Mar 3 20:34:26 PST 2012


"H. S. Teoh" <hsteoh at quickfur.ath.cx> wrote in message 
news:mailman.372.1330833051.24984.digitalmars-d at puremagic.com...
>> 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. 




More information about the Digitalmars-d mailing list