[AA] Disallow non-immutable types as associative array keys

[dlangBugzillaToGithub]

Denis Shelomovskii (@denis-sh) reported this on 2014-03-30T01:18:35Z

Transferred from https://issues.dlang.org/show_bug.cgi?id=12491

CC List

• Martin Nowak (@MartinNowak)
• Steven Schveighoffer (@schveiguy)

Description

Currently associative arrays are implemented with an assumption its keys hash will not change. The only way to enforce it is to disallow non-`immutable` (more correct not implicitly convertible to `immutable`) types as associative array keys. E.g. `int` and `string` keys will still work, `const(char)[]` will not.

This will cause a massive code breakage when e.g. mutable classes are used as keys. Note such uses are potentially error-prone and incorrect but looks like we have already inclined a lot of D users with such pattern.

[dlangBugzillaToGithub]

code (@MartinNowak) commented on 2015-07-21T09:49:11Z

How about something less drastic, e.g. AA's only allow const access to their keys?

> This will cause a massive code breakage when e.g. mutable classes are used as keys.

That's almost the same as disallowing classes as keys.

[dlangBugzillaToGithub]

schveiguy (@schveiguy) commented on 2015-07-21T13:23:40Z

(In reply to Martin Nowak from comment #1)
> How about something less drastic, e.g. AA's only allow const access to their
> keys?

That doesn't help. Const access doesn't mean nobody has mutable access.

Consider that the most common source of an error here is not that someone gets the key from the AA, but rather that he has a mutable pointer to the key from another source that he doesn't realize will affect the AA.

I personally think AAs simply shouldn't enforce any immutability. Enforcing const is useless, and enforcing immutable makes keys that aren't written with immutability in mind unusable. The result is, if you use a mutable key type for an AA, don't change any of the keys, or the AA doesn't work any more (note that this won't cause corruption, just leakage, so it can still be @safe).

In addition, immutability of the *entire* key isn't necessary. You could have members that are mutable but don't affect the hash/equal calculation. It would be impossible for the compiler to enforce this. I'd rather just leave it up to the user.