On Tue, Jan 3, 2012 at 1:50 PM, simendsjo <[email protected]> wrote: > On 03.01.2012 20:41, Andrew Wiley wrote: >> >> On Tue, Jan 3, 2012 at 1:25 PM, simendsjo<[email protected]> 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.
