Behaviour of AAs after initialization

[via Digitalmars-d]

On Thursday, 7 August 2014 at 18:05:15 UTC, H. S. Teoh via 
Digitalmars-d wrote:
> On Thu, Aug 07, 2014 at 05:42:28PM +0000, via Digitalmars-d 
> wrote:
>> On Thursday, 7 August 2014 at 17:35:46 UTC, Puming wrote:
>> >So I'd like to suggest a rule here similar to what assignment 
>> >does to
>> >null AA:
>> >
>> >If someone refers to an uninitialized null AA ( in 
>> >implementation,
>> >that maybe, a copy of a null AA struct happens), allocate it 
>> >first.
>> 
>> I'm afraid that copying is too general. This would trigger on 
>> just
>> about any access. It would also make copying AAs more 
>> expensive. I
>> believe a standardized method for initializing an AA is more 
>> likely to
>> be accepted.
>
> It really just needs a standard function in druntime that does 
> this.
> Perhaps something like this:
>
> 	// in object.di
> 	T initialize(T : V[K], V, K)(T aa = null) {
> 		aa[K.init] = V.init;
> 		aa.remove(K.init);
> 		// or if you like, encapsulate this in aaA.d and just
> 		// allocate Impl without the add/delete hackery.
>
> 		return aa;
> 	}
>
> 	// in user code
> 	auto aa = initialize!(string[int]);
>
> The name / syntax is up for bikeshedding, but the idea is 
> pretty simple.
> Make a druntime function that allocates the initial empty AA, 
> and make
> that function accessible to user code.
>
>
> T

It should take aa by ref, but then the default value needs to go. 
(Not a problem, just add a second overload.)

     T initialize(T : V[K], V, K)(ref T aa) {
         aa[K.init] = V.init;
         aa.remove(K.init);
         return aa;
     }

     T initialize(T : V[K], V, K)() {
         T aa;
         return initialize!T(aa);
     }

     // in user code
     auto aa = initialize!(string[int]);
     string[int] bb;
     bb.initialize();