More magical AA semantics

[Don]

On Friday, 11 January 2013 at 08:26:54 UTC, Jonathan M Davis 
wrote:
> On Friday, January 11, 2013 08:53:44 Don wrote:
>> Consider this code:
>> ---
>>     int[int] x;
>> 
>>     int k = x[2] + 5; // Error, range violation. Makes sense.
>> 
>>     x[2] = x[2] + 5;  // But this works!!!
>> ---
>> 
>> That is, x[2] doesn't exist, *unless you are about to assign to
>> it*.

>> How could this be implemented as a library type?


> I would argue that the fact that
>
> x[2] = x[2] + 5;
>
> works is a bug. Given some of the weirdness that happens with 
> assigning to AA
> elements, it doesn't entirely surprise me. For instance,
>
> x[2] = funcThatThrows();
>
> results in x[2] holding the init value of x's element type. But 
> I think that
> it's indicative of problems with the current AA implementation 
> which need to
> be fixed and not something that we should be trying to emulate 
> with library
> types.

That's my feeling too. I think that if we want to implement AAs 
as a library type, we first need to eliminate all of the 
semantics would be impossible to implement in a library.

Specificially, I think we need to disallow semantics which are 
inconsistent with:

struct AA
{
   AAImpl impl;

   ref Value opIndex(Key key);
   Value opIndexAssign(Value value, Key key);
   Value opIndexOpAssign(string op)(Value value, Key key);
}

where the last two create the entry if it doesn't already exist.

Those last two should also create a blank AA if it doesn't 
already exist.
Personally I'd be much happier if instead, the blank AA was 
created at construction, so that AAs would be pure reference 
types, but at least the semantics are implementable.