Proof of concept - library AA

[Martin Nowak via Digitalmars-d]

On Friday, 29 May 2015 at 21:58:16 UTC, IgorStepanov wrote:
> I suggest you to answer to the following two question:
> 1. What way to transit to the new AA would be acceptable?

One that doesn't break any code, carefully deprecates necessary 
semantic changes, and provides an improved implementation.

> 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".

The objection was too much code breakage for an inferior 
implementation.
https://github.com/D-Programming-Language/druntime/pull/934#issuecomment-66888409

> We may insert additional checks, see aaLiteral attributes, and 
> raise deprecation message, if attributes are inacceptable.

Maybe we can hack around the attribute incompatibilities in the 
compiler, we'll have to add deprecations at some point anyhow.

> 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.

- error messages
- attributes
- literals (especially polysemous initializers, i.e. ubyte[ubyte] 
aa = [0:1, 1:2])
- implicit tail const conversion Val[Key] -> const(Val)[Key]
- lots of magic around making Key const
- delete aa[key]
- lots of other small details (grep for Taarray in 
src/expression.c)

This is a heavily used built-in type, we can't risk a rewrite 
that breaks lots of code.