Implement setindex for ImmutableDict by danielmatz · Pull Request #59880 · JuliaLang/julia

danielmatz · 2025-10-17T22:36:47Z

This adds a method of Base.setindex for Base.ImmutableDict, as suggested in JuliaObjects/Accessors.jl#216.

For a key that is already in the ImmutableDict, rather than add it again and shadow it, as described in the ImmutableDict doc string, I opted to exclude the original key and then add in the new one.

giordano · 2025-10-17T22:53:45Z

This is a bit misleading since it isn't changing the original dictionary but creating a new one.

vtjnash

This makes the complexity of ImmutableDict worse than Vector{Pair}, which is never useful

danielmatz · 2025-10-18T19:12:35Z

This is a bit misleading since it isn't changing the original dictionary but creating a new one.

Did you perhaps misread this as setindex!? This change is about Base.setindex. It is already implemented for Tuple, NamedTuple, and CartesianIndex, where it creates a new value with the index changed.

This makes the complexity of ImmutableDict worse than Vector{Pair}, which is never useful

Whenever I make a PR for Julia, it never takes me long to get in over my head... So, take this all with a grain of salt. But the more I look at Base.ImmutableDict, the more questions I have.

When I saw ImmutableDict, I thought it would be a fairly general purpose, immutable version of Dict. But that doesn't seem to be the case. It really is an association list, right? Why wasn't it just called AssociationList? I understand that an immutable dictionary can be implemented as an association list, but the implementation details seem to be leaking out a lot here.

I think my main question is whether ImmutableDict wants to be an immutable dictionary or an association list.

The most apparent ways it violates the expectations of a dictionary is the behavior of keys, iterate, show, etc. All keys, including the shadowed ones, are included.

julia> d = Base.ImmutableDict(:a => 1, :b => 2, :a => 3)
Base.ImmutableDict{Symbol, Int64} with 3 entries:
  :a => 3
  :b => 2
  :a => 1

julia> keys(d)
KeySet for a Base.ImmutableDict{Symbol, Int64} with 3 entries. Keys:
  :a
  :b
  :a

julia> values(d)
ValueIterator for a Base.ImmutableDict{Symbol, Int64} with 3 entries. Values:
  3
  2
  1

julia> collect(d)
3-element Vector{Pair{Symbol, Int64}}:
 :a => 3
 :b => 2
 :a => 1

I worry that users will iterate over an ImmutableDict and accidentally operate on the shadowed entries. The doc string says that adding a key again makes the old value "partially overridden and hidden," but that's probably not enough detail to help users. And there's a comment in the code warning to not use iterate for certain operations, but that also doesn't help users.

As another example, consider this:

julia> d1 = Base.ImmutableDict(:a => 1, :a => 2)
Base.ImmutableDict{Symbol, Int64} with 2 entries:
  :a => 2
  :a => 1

julia> d2 = Base.ImmutableDict(:a => 2, :a => 1)
Base.ImmutableDict{Symbol, Int64} with 2 entries:
  :a => 1
  :a => 2

julia> d1[:a]
2

julia> d2[:a]
1

julia> d1 == d2
true

Is this a bug? No matter whether ImmutableDict wants to be a dictionary or an association list, this seems wrong.

Getting back to my PR. If ImmutableDict is meant to be an association list, then an implementation like

function setindex(d::ImmutableDict, value, key)
    ImmutableDict(d, key => value)
end

seems appropriate, and I can change this PR to do that.

But if it is meant to be an immutable dictionary, then my original implementation seems better, despite the higher complexity, because it actually behaves like a dictionary.

vtjnash · 2025-10-19T23:39:58Z

It could have been an AssociationList (taking the name from some lisps), to emphasize that implementation detail. But lisps seem to commonly emphasize implementation details rather than the abstract concepts when naming things. Elsewhere it is more common to refer to this as a generalization of a dict, e.g. https://pypi.org/project/multidict/ and https://en.cppreference.com/w/cpp/container/unordered_multimap/find.html and others in https://en.wikipedia.org/wiki/Multimap

cstjean · 2025-10-20T00:50:54Z

setindex can do its job (as a getindex inverse) efficiently without removing the previous entry.

The AbstractDict interface doesn't seem to be defined anywhere. I'm uncomfortable with keys() returning duplicates, but I can't really make an argument against it. Its docstring doesn't preclude it, at any rate.

This adds a method of `Base.setindex` for `Base.ImmutableDict`, as suggested in JuliaObjects/Accessors.jl#216.

danielmatz · 2025-10-25T18:15:35Z

Thanks for the discussion everyone. I updated my implementation of Base.setindex to match the design of ImmutableDict (existing keys are left in the dictionary).

I still think the behavior of ImmutableDict is surprising. I understand the parallels to multidict/multimap. Perhaps the name ImmutableMultiDict would have been nicer, then?

I know we can't rename it since it's already public. But I tried to clarify the behavior and usage in the doc string. If you all want that in a separate PR, I'm happy to do that.

danielmatz · 2025-10-25T18:41:22Z

I guess one open issue is the equality of ImmutableDicts when the order of the key => value pairs doesn't match. Is that a bug?

Several functions and types introduced in Julia 1.13 were missing `!!! compat "Julia 1.13"` annotations in their docstrings, and some were absent from the API reference docs entirely. Add compat notes to: - `Iterators.nth` (base/iterators.jl) - `@__FUNCTION__` (base/runtime_internals.jl) - `Base.AbstractOneTo` (base/range.jl) - `Base.setindex(::ImmutableDict, ...)` (base/dict.jl) - `isassigned(::Tuple, ::Integer)` (base/tuple.jl; also adds docstring) - `Base.active_manifest` (base/initdefs.jl) - `macroexpand` `legacyscope` kwarg and `macroexpand!` (base/expr.jl) - `AbstractSpinLock` and `PaddedSpinLock` (base/locks-mt.jl) - Type annotation support in `gen_call_with_extracted_types` (stdlib/InteractiveUtils/src/macros.jl) Add missing `@docs` entries to the API reference for: - `Base.Iterators.nth` (doc/src/base/iterators.md) - `Base.AbstractOneTo` (doc/src/base/collections.md) - `Base.setindex(::ImmutableDict, ...)` (doc/src/base/collections.md) - `Base.isassigned(::Tuple, ::Integer)` (doc/src/base/arrays.md) - `Base.@acquire` (doc/src/base/parallel.md) - `Base.ScopedValues.AbstractScopedValue` (doc/src/base/scopedvalues.md) - `Base.ScopedValues.LazyScopedValue` (doc/src/base/scopedvalues.md) Also declare `Base.setindex` as public in base/public.jl, which was inadvertently omitted from the original PR (JuliaLang#59880), and fix `nth` → `Iterators.nth` in HISTORY.md following the rename in JuliaLang#61486. Co-Authored-By: Claude <claude@users.noreply.github.com>

github-actions bot assigned JeffBezanson Oct 17, 2025

vtjnash requested changes Oct 18, 2025

View reviewed changes

danielmatz added 2 commits October 25, 2025 13:02

Implement setindex for ImmutableDict

3da4606

This adds a method of `Base.setindex` for `Base.ImmutableDict`, as suggested in JuliaObjects/Accessors.jl#216.

Elaborate on the behavior of ImmutableDict in its doc string

ddcff77

danielmatz force-pushed the setindex-immutabledict branch from a2de8f0 to ddcff77 Compare October 25, 2025 18:12

aplavin mentioned this pull request Oct 26, 2025

Implement setindex for Base.ImmutableDict JuliaObjects/Accessors.jl#217

Open

DilumAluthge assigned vtjnash and unassigned JeffBezanson Jan 31, 2026

vtjnash self-requested a review February 3, 2026 20:41

vtjnash approved these changes Feb 3, 2026

View reviewed changes

vtjnash merged commit 31215b6 into JuliaLang:master Feb 3, 2026
5 of 7 checks passed

IanButterworth mentioned this pull request Apr 7, 2026

base/docs: Add missing compat notes and docs entries for 1.13 features #61529

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Implement setindex for ImmutableDict#59880

Implement setindex for ImmutableDict#59880
vtjnash merged 2 commits intoJuliaLang:masterfrom
danielmatz:setindex-immutabledict

danielmatz commented Oct 17, 2025

Uh oh!

giordano commented Oct 17, 2025

Uh oh!

vtjnash left a comment

Uh oh!

danielmatz commented Oct 18, 2025 •

edited

Loading

Uh oh!

vtjnash commented Oct 19, 2025

Uh oh!

cstjean commented Oct 20, 2025

Uh oh!

danielmatz commented Oct 25, 2025

Uh oh!

danielmatz commented Oct 25, 2025

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

Uh oh!

Conversation

danielmatz commented Oct 17, 2025

Uh oh!

giordano commented Oct 17, 2025

Uh oh!

vtjnash left a comment

Choose a reason for hiding this comment

Uh oh!

danielmatz commented Oct 18, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

vtjnash commented Oct 19, 2025

Uh oh!

cstjean commented Oct 20, 2025

Uh oh!

danielmatz commented Oct 25, 2025

Uh oh!

danielmatz commented Oct 25, 2025

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

danielmatz commented Oct 18, 2025 •

edited

Loading