Proof of concept - library AA

[IgorStepanov via Digitalmars-d]

On Friday, 29 May 2015 at 17:52:58 UTC, Martin Nowak wrote:
> On Friday, 29 May 2015 at 13:12:58 UTC, IgorStepanov wrote:
>> What do you want about this syntax? Maybe you may suggest a 
>> better solution?
>
> The discussion drifts a little OT, if we have opIndexCreate, 
> then the library AA can be more compatible, but it still won't 
> be a drop-in replacement.

We went a long way in this direction and if we don't come to the 
result yet, that, I think, we haven't thought-out plan.

I suggest you to answer to the following two question:
1. What way to transit to the new AA would be acceptable?
You rejects my way (and I could not continue to work in the 
winter), and AFAIR you principial objection was: "aaLiteral is 
non- at safe for the unsafe code and it is breakage". However, 
aaLiteral attributes hasn't checked by compiler, because it was 
used in e2ir. _d_assocarrayliteralTX is not @safe or pure, but aa 
can be used in @safe pure code. We may insert additional checks, 
see aaLiteral attributes, and raise deprecation message, if 
attributes are inacceptable.
If it is the last objection, we may repeat compiler-side part for 
the new AA template. Othrewice, lets invent another way.

2. What issues disallows us to implement full library AA? Except 
.stringof, .mangleof, and other compiler magic.
I see only two issues: opIndexCreate and building aa from 
literals.