On 14/03/2012 19:24, H. S. Teoh wrote:
<snip>
Exactly. AA keys must be immutable, no matter what. Of course, to
interact nicely with existing code, methods like .opIndex or .get should
also accept mutable keys for lookup purposes, and .idup them when a new
entry needs to be created.
This would rely on class authors making sure they define .idup. We would also need a deep
version of .idup for array-of-array and array-of-class types.
<snip>
(d) guarantees that changes to the data that mess up the data
structure will never happen, at least if the programmer doesn't bypass
the const system.
[...]
I believe this is the best way to go. Well, at least for AA's this is
needed. Otherwise there will always be the possibility that AA's will
malfunction when the key changes behind the container's back.
Thinking about it, if we're going to go this far, maybe we could just make the key type
fully immutable whatever it is. This would enable the key variable in a foreach to be ref
for efficiency (especially useful if it's a struct type) and still prevent changing of the
key through it.
But this precludes implementing hash slots as arrays, at least if you want to be able to
delete elements. I might have to rethink my strategy here as well. A linked list would
get around it but increase the memory allocation overhead - not sure if this is worth
worrying about.
Stewart.
