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