Associative Arrays in the data segment

[Daniel Murphy via Digitalmars-d]

"H. S. Teoh via Digitalmars-d"  wrote in message 
news:mailman.1420.1428683081.3111.digitalmars-d at puremagic.com...

> The bigger problem is that this binds us even more to the current
> schizophrenic split of the AA implementation between the compiler and
> druntime.

No, it doesn't.

> We've been trying to break away from that for years, and now
> you're suggesting to bring us back to square one.

No, I'm not.

> Didn't somebody (IIRC Igor Stepanov?) submit a bunch of PRs in this
> direction? I.e., precisely to factor out AA-specific interfaces in the
> compiler so that everything goes through a standard API that eventually
> can be swapped for proxies to a library implementation? While it's true
> I haven't seen activity on this front for a while now, I was under the
> impression things were moving along quite well. If we all were to get
> behind this effort and push it through instead of going back to the bad
> ole split-implementation approach, maybe it would have seen the light of
> day already.

We're not going back to anything, it's an improvement to the current 
implementation.

I'd love to be proven wrong, but what you said is not likely to happen. 
Instead people are going to say "we should do it this way!" and nothing will 
get done.  And even if it did happen, it would replace the code I'm adding, 
not conflict with it.  ie this change is a new glue layer expansion of 
AssocArrayLiteralExp, and with a library AA that expression would already be 
converted to a struct literal/class exp/etc.

The only argument I've heard against this change that actually has merit is 
that it will make it harder to change the internals of the current AA.  I'm 
happy to provide compiler versions of any new druntime AA implementations, 
it's not very difficult.