Revamping associative arrays

Max Samukha spambox at d-coding.com
Sun Oct 18 01:12:19 PDT 2009


On Sat, 17 Oct 2009 22:47:21 +0200, grauzone <none at example.net> wrote:

>Max Samukha wrote:
>> On Sat, 17 Oct 2009 13:28:51 -0500, Andrei Alexandrescu
>> <SeeWebsiteForEmail at erdani.org> wrote:
>> 
>>> Associative arrays are today quite problematic because they don't offer 
>>> any true iteration. Furthermore, the .keys and .values properties create 
>>> new arrays, which is wasteful.
>>>
>>> Another issue with associative arrays is that ++a[k] is hacked, which 
>>> reflects a grave language limitation. That needs to be replaced with a 
>>> true facility.
>>>
>>> Any other issues with AAs that you want to see fixed, and ideas guiding 
>>> a redesign?
>>>
>>>
>>> Thanks,
>>>
>>> Andrei
>> 
>> They should be true reference types. Now we have oddities like this: 
>> 
>> int[int] a;
>> auto b = a;
>> a[1] =  2;
>> assert(b[1] == 2); // Range violation
>> 
>> int[int] a;
>> a[1] =  2;
>> auto b = a;
>> a[2] = 3;
>> assert(b[2] == 3); // Ok
>
>That's because the actual AA is allocated on demand (when you add the 
>first element). The new array type T[new] is going to have the same 
>"problem".

I agree. But the problem is the lack of a decent way to instantiate an
empty AA. Now you either have to do idiotic things like:

int[int] a;
a[1] = 1;
a.remove(1);

Or wrap the array in another type. 

And, talking about T[new], we should be able to instantiate them
eagerly as well.

>
>I like it, because if you don't need it, it doesn't allocate memory. Of 
>course it's possible that the complication in semantics isn't it worth. 
>But D is still a systems programming language with a *very* bad GC, 
>which is why I think it should continue to work this way.



More information about the Digitalmars-d mailing list