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