Behaviour of AAs after initialization

H. S. Teoh via Digitalmars-d digitalmars-d at puremagic.com
Thu Aug 7 11:03:35 PDT 2014


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

-- 
Some ideas are so stupid that only intellectuals could believe them. -- George Orwell


More information about the Digitalmars-d mailing list