[dmd-internals] AssociativeArray in druntime should go before the next release

[Andrei Alexandrescu]

Ouch. We definitely need to fix this, apologies for unknowingly breaking 
so much stuff.

Long term we must adjust the compiler to simply lower special AA 
notation into "regular" D code so we can rely on the library 
implementation. I'm not sure what the best route would be for CTFE 
(special-case AAs vs. interpreting the implementation in object.d).

BTW what's the awful thing you mention in object.di? You mean the cast 
must be interpreted during compilation?


Andrei

On 2/2/12 7:46 AM, Don Clugston wrote:
> I agree completely. In Bugzilla, I found FIFTEEN reported compiler
> regressions caused by the introduction of library AAs. Most were very
> difficult to fix; in many cases the fix is very fragile.
>
> Another issue that wasn't on your list: AA literals don't have a
> representation outside of the compiler, yet they are a crucial
> implementation issue.
>
> Take at look at this code in object.di, it's really incredible:
>
> struct AssociativeArray(Key, Value)
> {
>     void* p; // really Hashtable*
>
>      Value get(Key key, lazy Value defaultValue)
>      {
>          auto p = key in *cast(Value[Key]*)(&p);<------ Think about
> what happens here.
>          return p ? *p : defaultValue;
>      }
> }
>
> The CTFE code to cope with this sort of thing is truly awful.
>
> The D2 AA implementation is a pack of cards. If you make a small
> change, it will break.
> And it's getting worse. So far, every fix has made the compiler more
> complicated and more closely tied to the runtime, in very subtle ways.
>
> I think we should cut our losses, and roll it back. This particular
> approach is a disaster.
> _______________________________________________
> dmd-internals mailing list
> dmd-internals at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-internals