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
[email protected]
http://lists.puremagic.com/mailman/listinfo/dmd-internals
_______________________________________________
dmd-internals mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/dmd-internals
