Sooo, when are we implementing this? 😁

https://dlang.org/spec/hash-map.html#static_initialization

On Tuesday, 18 May 2021 at 08:08:10 UTC, Chris Piker wrote:

AA are definitely a great D feature IMO. But unlike other D features, they are not as composable as we'd like.

Take slices for example. They compose fairly well. You can get an int[] from the GC, a static array, malloc, or even some other library-provided buffer. While extending them is tied to the GC (a ~= b will always call the GC), sub-slicing them, batch operations (a[] = b or a[] = b[]) will work just the same no matter what underlying memory you have.

Associative arrays have none of that. They are tied to the way they've been implemented in the runtime, and predate a lot of features. They only work with qualifiers because of the C interfacing. You can't control the underlying memory, which means you can't reuse it or bind it to a buffer if you know the AA size in advance. They don't work well with qualifiers, because the compiler will error on myAA[key] = value; if is(typeof(myAA[key]) : const) because it can't know if it's an update or an insertion. We have require and update in druntime but those are not recognized by the compiler so they don't solve the problem.

The following doesn't even compile:

void main () nothrow
{
    int[int] aa;
    foreach (k, v; aa) {}
}

Because:

Now as to why AA don't work at CT: They still use the "old" druntime approach, namely hiding all runtime magic behind extern(C) functions which are declared in the compiler frontend and defined in druntime (the linker doing the magic). This approach has the "upside" of bypassing all attributes checks (you can say that a function is @safe pure nothrow @nogc in the compiler frontend but not mark it as such in the extern(C) function and things will link), but it has many downsides: First, it's not CTFEable, meaning many things depending on the runtime had to be duplicated in the frontend; second, it can hurt performances, as it can't be inlined (although LTO might do a good job here); lastly, well, it bypass all attributes checks so when you actually have a mismatch all hell breaks loose.

There's been a few discussions about this over the year. For example, this PR from a few years ago wanted to at least allow builtin types. @IgorStepanov did some work, e.g. here and here (and more). Martin Nowak IIRC also did quite some work on it.

On Tuesday, 18 May 2021 at 08:22:56 UTC, Ola Fosheim Grostad wrote:

That's an interesting take.

So far, with only a month's usage of D I'm seeing so much meta-programming capability that it actually worries me a bit. With string mixins and so many other meta programming features around I'm starting to think that reading other people's D code is going to be quite difficult, similar to perl.

This sounds like a reasonable position. Imagine for a second that AAs were implemented as a library. What would the library equivalent of this:

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

look like?

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

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

https://github.com/dlang/druntime/blob/bf21d1bad623c6988d644117c3c0aa4d4f08b771/src/object.d#L2657-L2660

The playground will show the call to _d_assocarrayliteralTX if you select ASM.

On Tuesday, 18 May 2021 at 08:54:00 UTC, Mathias LANG wrote:

Thanks for the description, that was informative :)

void main () nothrow
{
    int[int] aa;
    foreach (k, v; aa) {}
}

So basically I can use AAs, so long as I don't put them in critical software since they are always going to throw. No trouble, I can live with that, it's good to know that up front.