Standalone AA implementation ready for review (Was: Re: Replacing AA's in druntime)

[Steven Schveighoffer]

On Thu, 15 Mar 2012 13:24:24 -0400, Andrei Alexandrescu  
<SeeWebsiteForEmail at erdani.org> wrote:

> On 3/15/12 12:12 PM, Steven Schveighoffer wrote:
>> On Thu, 15 Mar 2012 12:05:46 -0400, Andrei Alexandrescu
>> <SeeWebsiteForEmail at erdani.org> wrote:
>>
>>> On 3/15/12 11:02 AM, Don Clugston wrote:
>>>> This is good, and very, very important. Do *not* make any attempt at
>>>> compiler integration until it is *completely* ready.
>>>>
>>>> This includes AA literals. They need to be accepted somehow. The
>>>> compiler will give you syntax sugar and *nothing* more.
>>>> One possibility might be to accept a pair of array literals,
>>>> representing keys and values.
>>>> Possibly it should call a CTFE function to convert them into some  
>>>> other
>>>> form?
>>>
>>> Offhand, I think this rewrite should be sufficient:
>>>
>>> [e11:e12, e21:e22]
>>>
>>> --->
>>>
>>> .object.associativeArrayLiteral(e11, e12, e21, e22)
>>>
>>> Then type manipulation and template constraints can take care of the
>>> rest. Am I missing something?
>>
>> Wouldn't this require a new template instantiation for each sized AA per
>> key/value type? Or were you planning to use varargs?
>
> Template function takes over, does whatever is necessary, such as  
> possibly conversion to varargs.

Right, but with a template:

[1:1]
[1:1, 2:2]

become two separate template instantiations, but with something that just  
takes two arrays, it's only one template, no matter how many elements you  
are initializing with.

>> So long as the data that is actually passed to the AA is on the stack
>> (and simply a slice is passed), I like Don's idea better.
>
> What would that look like?

auto aa = [1:1];

  becomes:

int[1] __k = [1]; // obviously, no heap allocation should happen here,  
that needs fixing in the compiler
int[1] __v = [1];
auto aa = AssociativeArray!(int, int)(__k, __v); // same instantiation, no  
matter how many elements are in literal.

-Steve