Associative arrays (page 3)

On Tuesday, 18 May 2021 at 12:57:01 UTC, Steven Schveighoffer > Let's make that 2 arrays (static or stack-allocated dynamic) to avoid the vararg template cost. That's good for current AAs, but it can't do the heterogeneous types. Of course that's illegal in D right now anyway I'm just holding out hope for an expansion for json literals w/o explicit constructors on each element too. :) but yeah that'd work just fine too.

On 5/18/21 9:04 AM, Adam D. Ruppe wrote: > On Tuesday, 18 May 2021 at 12:57:01 UTC, Steven Schveighoffer >> Let's make that 2 arrays (static or stack-allocated dynamic) to avoid the vararg template cost. > > That's good for current AAs, but it can't do the heterogeneous types. > > Of course that's illegal in D right now anyway I'm just holding out hope for an expansion for json literals w/o explicit constructors on each element too. :) > > but yeah that'd work just fine too. Hm... that does kind of make sense. I was thinking maybe you could specify the type of key to be something that accepts multiple constructor values (like translate to Json(val)) but then the expression isn't self-contained, it has to look at what it's being assigned to (which also is a possibility, after all, AA literal assignment can get type hints from the thing it's being assigned to). I hope there's some way to avoid paying the variadic template penalty tax, which would be pretty heavy if you had a large literal (not uncommon). -Steve

On Tuesday, 18 May 2021 at 19:34:45 UTC, Chris Piker wrote:

On Tuesday, 18 May 2021 at 13:25:32 UTC, Paul Backus wrote:

On Tuesday, 18 May 2021 at 09:14:46 UTC, Chris Piker wrote:

What would the library equivalent of this:

long[string] aa = ["foo": 5, "bar": 10, "baz": 2000 ];

look like?

Something like this, most likely:

auto aa = makeAA!(string, long)("foo", 5, "bar", 10, "baz", 2000);

So if I understand correctly, the idea is to get rid of AAs and replace them with moral equivalent of a Java HashMap. I'm guessing this means array index and assignment would become something like:

   value = aa(key);
   aa(key, value);

and AAs as a language construct would disappear. Or would the current syntax remain via CTFE?

We would keep the existing syntax, but lower it to something else

May 18, 2021

Re: Associative arrays

Posted by Paul Backus
in reply to Chris Piker

Permalink

Paul Backus

Posted in reply to Chris Piker

Permalink

On Tuesday, 18 May 2021 at 19:34:45 UTC, Chris Piker wrote:

So if I understand correctly, the idea is to get rid of AAs and replace them with moral equivalent of a Java HashMap. I'm guessing this means array index and assignment would become something like:

   value = aa(key);
   aa(key, value);

and AAs as a language construct would disappear. Or would the current syntax remain via CTFE?

D allows overloading the index operator, so you would still be able to write

value = aa[key];
aa[key] = value;

As far as I know the only thing D's operator overloading doesn't support that the built-in AA syntax does is insertion of values into nested AAs with a single assignment:

bool[string][string] aa; // NB: empty AA of AAs
aa["foo"]["bar"] = true; // assigns both aa["foo"] and aa["foo"]["bar"]

With a library type, you would instead have to write:

Map!(string, Map!(string, bool)) aa;
aa["foo"] = new Map!(string, bool);
aa["foo"]["bar"] = true;

Forums