Proof of concept - library AA

[Martin Nowak via Digitalmars-d]

On Saturday, 30 May 2015 at 01:32:26 UTC, IgorStepanov wrote:
>> - attributes
> We will able to deprecate attribute violations in transitional 
> version (with vtbl).

Yes, we'd have to deprecate attribute issues of the built-in AA 
before we can switch.
Maybe that's already to disruptive.

>> - literals (especially polysemous initializers, i.e. 
>> ubyte[ubyte] aa = [0:1, 1:2])
> Yes, this is the first main trouble.

We could possibly make the array of types polysemeous as well and 
deduce the type from the constructor argument.

>> - implicit tail const conversion Val[Key] -> const(Val)[Key]
> May be we may add "alias this"-es for all all those variants?
> Something like ...
> struct AA(K, V)
> {
>     alias getCKeyMval this;
>     alias getMKeyCval this;
>     alias getCKeyCval this;
>     @property {
>     ref AA!(const(K), V) getCKeyMval() { return 
> *cast(typeof(return)*)&this; }
>     ref AA!(K, const(V)) getMKeyCval() { return 
> *cast(typeof(return)*)&this; }
>     ref AA!(const(K), const(V)) getCKeyCval() { return 
> *cast(typeof(return)*)&this; }
>     }
> }

"overload" by return type? Maybe.

> We should start to try to find and solve them.

The list is pretty long, there are lots of unknowns.
I'd rather choose an incremental approach that allows for 
intermediate failure.