Comment #0 by verylonglogin.reg — 2014-03-30T02:02:34Z
Currently there is no clear rules about types which can be used to get associative array key value, e.g. one may expect to be able to get `int[string]` AA value using `char[]` and vice-versa.
In case of setting value it's simple, a key expression type should be implicitly convertible to associative array key type (i.e. we need just fix Issue 2954). The case of getting AA value is more complicated because all we need is:
1. Ability to compare values of these types.
2. Equality of hash sums of equal values of these types.
So at least this mean `const`/`immutable` type qualifiers can be ignored iff we always use same hash algorithms regardless of type qualifiers.
It's a bug, not an enhancement because current compiler behaviour is inconsistent, e.g. it allows getting `int[Object[]]` AA value using `immutable Object[]` but disallows getting `int[Object]` AA value using `immutable Object` and even `const Object`.
Also see Issue 12491 about the idea to disallow any non-`immutable` types as associative array keys.
Comment #1 by acehreli — 2016-11-15T08:28:46Z
I hit this problem in a const member function where the member type of .values turned out to be const:
struct S {
int[char[]] aa;
void constFunc() const {
static assert(is(typeof(aa.keys[0]) == const(char)[])); // Passes, good
static assert(is(typeof(aa.values[0]) == int)); // FAILS
}
}
void main() {
}
(In my particular case, I had attempted to sort the copy of values, which had failed due to const(int) members.)
Note that the workaround of declaring a non-const array is totally safe:
int[] values;
foreach (v; aa.byValue) {
values ~= v;
}
Of course functional style with .byValue would still produce the wrong type:
auto values = aa.byValue.array;
static assert(is(typeof(values[0]) == int)); // FAILS
Ali
Comment #2 by robert.schadek — 2024-12-13T18:19:02Z