On Fri, 08 Apr 2011 14:57:52 -0400, spir <[email protected]> wrote:
On 04/08/2011 03:13 PM, Steven Schveighoffer wrote:
On Fri, 08 Apr 2011 06:44:42 -0400, Simen kjaeraas
<[email protected]> wrote:
On Fri, 08 Apr 2011 12:46:08 +0200, Morlan <[email protected]> wrote:
It is OK if I write
int[char[]] asr;
asr["hello"] = 10;
but the following does not compile:
char[] car = "hello";
What is the explanation for this behaviour?
The first should not be allowed. It is a mistake to use non-immutable
keys for an associative array.
int[char[]] asr;
pragma(msg, typeof(asr).stringof);
outputs:
AssociativeArray!(const(char)[],int)
So the compiler adds const to the keys, which is why it works.
Do I think this is the correct behavior? Absolutely not. First, it
prevents
nothing as far as modifying keys (const accepts mutable keys as well as
const
and mutable ones). Second, I believe you should be able to use whatever
key
constancy you want. We should just say if you do the wrong thing, it's
undefined. Maybe @safe code can only use immutable keys. Third, if it
must be
illegal to have an AA with mutable keys, it should be an error, not
silently
change to const.
I agree on points 1 & 3. "Second" looks dangerous to me.
Dangerous, yes. But immutable objects are typically not easy to deal
with. For one, you can't have tail-immutable objects (currently), so
implementation of such a container is going to be a pain. In fact,
dcollections simply doesn't work if you have fully immutable types as keys.
In reality, most times you are not using something as a key and somewhere
else simultaneously. So while theoretically dangerous, it's easy to write
code that isn't dangerous.
-Steve
