Why isn't keys defined on SparseAxisArray?

In my code, I mostly use SparseAxisArray as an equivalent for dictionaries, except that it’s returned by JuMP. Thus, I’m trying to use keys on a SparseAxisArray, but it’s not behaving as expected, returning a DenseAxisArrayKeys. Actually, the most annoying part in this is when I’m using the in operator: idx in keys(container), which always yields false, even though the index is valid for the container.

eachindex is not really a solution, as it returns a series of CartesianIndex, which I’m not using (I prefer indexing with concrete things that make sense for my optimisation problem, such as an edge in a graph). Using the container.data field is neither clean nor working; I have to use the original container I used to define the variable (which is sometimes problematic, as it must then get passed around in my code along with JuMP’s container, even though JuMP’s container is supposed to have this information somewhere).

Is there a design decision I missed or a quality-of-life improvement needed?

There’s an open issue: Unify treatment of `keys` on JuMP containers. · Issue #1988 · jump-dev/JuMP.jl · GitHub

Thanks, I did not see that issue!

Is there any consensus about what to do about it?

I don’t think anyone has worked on it. If you want to investigate and propose/implement a. PR, help would be appreciated!

We just developed in SparseAxisArray enough features so that there is not regression between JuMP v0.18 and JuMP v0.19.

I mostly use SparseAxisArray as an equivalent for dictionaries

The goal is for the user code to work seemlessly with either of the 3 containers (Array, DenseAxisArray or SparseAxisArray) so that it’s possible to not worry about which one is picked. So it’s not supposed to act like a dictionary. If it’s possible to add features that are provided by dictionaries without creating inconsistent behaviors with other containers then the feature is welcome of course.