More magical AA semantics

[monarch_dodra]

On Saturday, 12 January 2013 at 21:56:13 UTC, Andrei Alexandrescu 
wrote:
> On 1/12/13 7:40 AM, Jonathan M Davis wrote:
>> On Saturday, January 12, 2013 13:30:47 monarch_dodra wrote:
>>> What about "++a[0]" when there is no a[0]? Is this something 
>>> that
>>> will throw or not?
>>
>> Personally, I think that it should, but there's probably a 
>> good chance that it
>> won't, because it's an lvalue. I don't know what will happen 
>> with that though.
>> There are a lot of bugs right now related elements being 
>> inserted into AAs
>> when they shouldn't be, so I really don't know how much 
>> relation the current
>> behavior will have with the behavior that AAs will ultimately 
>> have.
>
> ++a[0] should work.

OK. But then let's also try to solve these standing issues:
Given a T[int], where T defines op++:

1. a[0] must be initialized to T.init first (and not memory 
zero'd, especially if T is user defined).
2. a must not be modified if T.op++ throws an exception.

Q. Is this specific to *operators* that mutate? What about normal 
function?:
   a[0].mutate();
     Q.1) create a T.init and call mutate on it?
     Q.2) Throw an exception

>>> As well, what about
>>> //----
>>> immutable(int)[int] aa;
>>> aa[0] = 5;
>>> //----
>>> This should work, right?
>>
>> That should definitely work. That's how you add elements to 
>> AA. My gripe with
>> something like ++a[0] working when there's no a[0] is that 
>> you'd be adding to
>> an element that doesn't exist yet.
>
> Shouldn't work.
>
> Andrei

I can see the problem: What if the key is already there?

However, I think this is just a limitation of the syntax. If AA's 
had an "insert" function that only inserts when the key doesn't 
exist (akin to C++'s set::insert), then we'd be able to have our 
AA's of immutables.