Re: 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();