Why use .init for associative arrays?

[Chris Nicholson-Sauls]

Chris Nicholson-Sauls wrote:
> Gilles G. wrote:
>> Hello,
>> I am just wondering why we should use init for associative arrays of 
>> structs. See this code for example:
>>     struct S
>>     {
>>         int nb;
>>     }
>>     void main()
>>     {
>>         S[char[]] aa; // associative array of struct S
>>         aa["this_is_good"] = S.init;
>>         aa["this_is_good"].nb = 1;      // all right
>>         aa["this_is_an_error"].nb = 1; // runtime error, compiles fine...
>>     }
>>
>> I can't see a use case for _not_ using init before accessing a new 
>> key, so why do we have to explicitely use S.init?
>> Why does this code compile fine (it gives an access violation error at 
>> runtime), shouldn't it always give an error?
>>
>> Regards.
>>
>> -- 
>> Gilles
>>
> 
> I would say this is because, until /assigned to/, AA pairs "don't 
> exist."  Since the member-access of the dot operator occurs "before" the 
> member-assignment, there is an attempt to dereference null.  The `= 
> S.init` idiom is just a convenient way to insert the new AA value.
> 
> -- Chris Nicholson-Sauls

Which later made me think of something.  Might it be useful for AA's to 
explose a .add(K) counterpart to the existing .remove(K) property? 
Usage being as follows:

V[K] aa ;
aa.add(K, someValue); // equivelant to 'aa[K] = someValue'
aa.add(K); // equivelant to 'aa[K] = V.init'

Or did something like this come along and I missed it?

-- Chris Nicholson-Sauls