AA char[] as key

[Andrew Wiley]

On Tue, Jan 3, 2012 at 1:50 PM, simendsjo <simendsjo at gmail.com> wrote:
> On 03.01.2012 20:41, Andrew Wiley wrote:
>>
>> On Tue, Jan 3, 2012 at 1:25 PM, simendsjo<simendsjo at gmail.com>  wrote:
>>>
>>> seems T[char[]] is rewritten as T[const(char)[]], and does not accept
>>> char[]
>>> as key even if mutable data should automatically convert to const
>>> (right...?)
>>>
>>>
>>> Shouldn't T[char[]] be disallowed, and have to be written as
>>> T[immutable(char)[]] instead of a silent rewrite?
>>>
>>>
>>>    alias long[char[]] AA;
>>>    // key automatically changed to const(char)[]
>>>    static assert(is(AA == long[const(char)[]]));
>>>    AA aa;
>>>    aa["a"] = 10;
>>>    // error - have to use immutable keys
>>>    aa["b".dup] = 11;
>>
>>
>> By design, the problem is things like this:
>>
>> char[] key = "somekey";
>> long[char[]] aa;
>> aa[key] = 5;
>> key[2] = 'b';
>>
>> If this were allowed, the associative array would reach an invalid
>> state where the hash it stored for the key is no longer correct.
>>
>> It does seem like T[char[]] should be disallowed and the requirement
>> for immutable keys should be literally enforced, and it's possible
>> that was intended but immutable/const weren't as complete when this
>> problem was last visited. I'll see if I can dig up an old discussion
>> about this.
>
>
> It is disallowed, but it's enforced when setting a key rather than when
> constructing the type.
> So `aa[key] = 5` above fails as key is char[] rather than string.

Yes, while that's correct, it doesn't make much sense (as you pointed
out). Rewriting long[char[]] to long[const(char)[]] isn't particularly
useful when you can't use char[] as a key.
If the compiler is basically going to disallow using the AA as
anything but a long[string], it should really disallow declaring
anything with a mutable key type. Disallowing mutable keys at that
assignment site but allowing them in the type is confusing.