Add ability to create T[int] AAs in the data segment

[yebblies]

It's not that hard to support at least built-in types for AA keys.

Any interest? If so I can do other integral types and strings pretty easily.

[MartinNowak]

This goes very much against what we should do with AAs.

• couples the runtime and compiler implementation of the hash table and the hashing algorithms (and we really need to improve those)
• adds more magic capabilities to the builtin AA (though it should be simple to support this in a library AA)
• adds another half implemented feature (yes you can have immutable AAs, but only with those values)

[yebblies]

couples the runtime and compiler implementation of the hash table and the hashing algorithms (and we really need to improve those)

Yes, although I'm happy to be responsible for updating the compiler implementation to match the druntime one, if/when it changes.

adds more magic capabilities to the builtin AA (though it should be simple to support this in a library AA)

I disagree, this is something that a library AA would/should support automatically.

adds another half implemented feature (yes you can have immutable AAs, but only with those values)

I don't think this matters. The current situation is much, much worse as nothing is supported. Not even the trivial cases. The error message can clearly point out which cases don't work.

Another year has gone by without a library AA becoming available. This should have worked a long time ago, even if it's only for the most common cases (integer/string keys).

[MartinNowak]

adds more magic capabilities to the builtin AA (though it should be simple to support this in a library AA)

I disagree, this is something that a library AA would/should support automatically.

So you actually agree ;).

Please let's not dissipate even more time going in the wrong direction, frustrating people, and trying to explain/document all of that.
What keeps you from supporting all kinds of keys and values, the hash computation?
That might be a useful intermediate step.

[yebblies]

adds more magic capabilities to the builtin AA (though it should be simple to support this in a library AA)

I disagree, this is something that a library AA would/should support automatically.

So you actually agree ;).

I... I don't think so. It's only magic if the library AA wouldn't support it. A library AA can be put in the data segment with the current compiler.

Please let's not dissipate even more time going in the wrong direction, frustrating people, and trying to explain/document all of that.

I think it's worthwhile, because this is a very frustrating limitation. I don't know when the library AA will be available. A year from now? Two? We can cover a huge number of use cases trivially by the next release.

I don't think this is going in the wrong direction at all, from the user's perspective. If a library AA was to be implemented, the code I've added would never be reached as the AA literal would have been lowered to a struct/class expression already, so it doesn't hurt that effort apart from raising expectations.

I think we've held back long enough, perfect is the enemy of better, etc

What keeps you from supporting all kinds of keys and values, the hash computation?
That might be a useful intermediate step.

Yeah, nothing too serious. Supporting user-defined hashes of classes/structs is quite complicated (have to invoke ctfe, could fail) but all built-in types can be done fairly easily. (And will be done soon probably)

[yebblies]

What keeps you from supporting all kinds of keys and values, the hash computation?

Oh and all values are supported now, the limitation is just for keys. I've edited the PR title.

[yebblies]

It's been 5 months and we still don't have AAs in the data segment.

[MartinNowak]

We'd have to maintain, document, and justify this, please let's not waste out scarce time for another sloppy half-done feature.
I recently made a proposal for a feasible implementation, but noone from the core team participated in the discussion.
dlang/druntime#1282

[ibuclaw]

FYI. It was a pain supporting the 'new class' misfeature, and I certainly don't want to reverse engineer another complex format.

AAs should be pushed into the library. I think this is the best direction to go in.

[MartinNowak]

Actually I agree w/ @ibuclaw, despite what we discussed at dconf.
My core.aa proposal is still up (dlang/druntime#1282) and should allow to store any AA at compile time.

[ibuclaw]

Yep. I've even used a (specialized) version of core.aa in other programs with relative success.

[yebblies]

I'll keep counting the years then.

[UplinkCoder]

@yebblies could you close this please ?

[yebblies]

After two years with no progress, might was well.