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

[Andrei Alexandrescu]

On 3/15/12 12:39 PM, Steven Schveighoffer wrote:
> On Thu, 15 Mar 2012 13:24:24 -0400, Andrei Alexandrescu
> <SeeWebsiteForEmail at erdani.org> wrote:
>> 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.

I guess I should ask this then: why is instantiating a template function 
a problem?

>>> 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.

That should work, too. Use braces to not require a fix:

int[1] __k = {1};
int[1] __v = {1};
auto aa = AssociativeArray!(int, int)(__k, __v);

Off the top of my head it changes the order of evaluation in the general 
case (or complicates code generation if left-to-right preservation is 
needed). Also the constructor needs to be @trusted because references to 
static arrays can't escape in safe code. All workable matters, but 
generally I prefer migrating cleverness from code generation into 
library code.


Andrei