Comment #0 by siegelords_abode — 2011-09-23T20:58:23Z
int[char[]] a;
int[immutable(char)[]] b;
char[] s;
int v1 = a[s]; // Fine
int v2 = b[s]; // Fine
a.remove(s); // Fine
b.remove(s); // Error: cannot implicitly convert expression (s) of type char[] to string
Can we be done with the compiler magic for the AA's?
Comment #1 by issues.dlang — 2011-09-23T21:15:55Z
The simplest solution is to just make it so that it's illegal to declare an AA with a key which isn't either a value type or immutable and make it so that _all_ functions or operators which take the key must take a type which is implicitly convertible to the key type (including its immutability). It _would_ break a fair bit of code though, I suspect. Still, it would be a fairly simple change to make in any code that it breaks, and it could be grandfathered in by making it a warning first.
Comment #2 by smjg — 2012-02-12T12:35:58Z
A char[] can be safely compared with an immutable(char)[], so the code should be valid.
Putting a value into an AA is another matter though.
(In reply to comment #1)
> The simplest solution is to just make it so that it's illegal to
> declare an AA with a key which isn't either a value type or
> immutable
Agreed.
> and make it so that _all_ functions or operators which take the key
> must take a type which is implicitly convertible to the key type
> (including its immutability).
For functions that put data into an AA, yes.
For lookup functions (retrieval and removal), it should be sufficient that it's a type that is implicitly convertible to the const version of the key type. (Just having an == operator with the key type isn't sufficient, as it needs to check the hash first.)
For foreach, the only requirement should be that the key variable is of a type to which the key type can be implicitly converted.
But this is a distinct matter from this bug.
Comment #3 by robert.schadek — 2024-12-13T17:56:30Z