I am currently implementing a custom
Dict type, which allows for different key and value types. This means that
iterate is not type stable, but many operations like
map can be implemented to be type stable. I was looking for a way to implement
map only to find that it isn’t implemented for dicts anymore. I stumbled upon the discussion on this PR where it was decided against adding a non-inplace
map for dicts. @stevengj brought up the following argument:
I think the current semantics of
map(f, values(dict))producing a new array of values is fine and is what I would expect from mapping the
valuesiterator, consistent with other iterators. We already have a non-mutating dictionary map via
Dict(k => f(v) for (k,v) in d), and you could also do
map!(f, values(copy(dict)))to avoid re-hashing the keys, so I’m not sure there is a need for a new function.
map!(f, values(dict)), which is currently an error, has only one possible reasonable meaning to me: modify the values of
The main value of this function is as a performance optimization in the in-place case, anyway; in a typical context where you are willing to make a copy of the dictionary, I’m guessing that the performance cost of re-hashing the keys is not such a big deal.
Dict(k => f(v) for (k,v) in d) and
map!(f, values(copy(dict))) rely on
iterate and therefore don’t make sense for certain
AbstractDicts like mine. I would also argue that something along the lines of
map(f, dict) is much more concise than both alternatives and I think many users would expect that to work since
NamedTuples already work that way. It would also make it easier to write generic code for different types of collections.
I can’t really see the benefit in not having such a function. One might still want to discuss, whether the function should have a different name and whether
f should take in a
Pair of key and value or just the value. Those are just my thoughts and use case though, feel free to discuss.
Thank you for making Julia so awesome!