Yeah, it's a bit sketchy, but the alternatives are: a) only allow immutable values as keys, which seems annoyingly finicky; or b) hash mutable values by identity, which seems really unintuitive. You can think of using a value as a dict key, as an implicit promise not to mutate it. Copying keys before storing them in dicts doesn't really solve the problem since you can still get a hold of the copy that's stored and mutate that; this is only slightly harder to do.
On Mon, Oct 13, 2014 at 12:07 PM, Tamas Papp <[email protected]> wrote: > As a Julia newbie, I see no problem with that. Modifying the keys of a > hash table is an operation with undefined consequences ("just don't do > it"), so the programmer should focus on good practices that prevent this > from happening (it is not that hard). > > The alternative is to only allow bits types or containers which are > immutable recursively (eg an immutable type which contains a mutable > container is ruled out). In practice, this can be done, bit it would > lead to a lot of boilerplate in case wants to use other types as keys. > > Best, > > Tamas > > On Mon, Oct 13 2014, nbbb <[email protected]> wrote: > > > as a julia outsider (for now), it seems odd to me that mutable containers > > are allowed as dictionary keys at all. > >
