Well, that sounds problematic, but the ones definition just the same, since it privileges ones over zeros 😉. Who says it's not a set of zeros?

Well, it can get a little philosophical... :)

But I guess there is some precedent to consider a FixedBitSet a set of ones. For example, for "zero" sets, there are no equivalents of:

1. clear(), to put all values to 1
2. with_capacity(), to create a set with no element
3. ones()
4. and maybe, most importantly, the methods intersection, union, difference, etc cannot be applied to "zero" sets.

I think it sounds ok, even though it's not a necessary change. What do you think @jrraymond ?

hmmm. I can see the argument for. Although I have reservations about making such a breaking change given that this is the first time a user has raised this issue in the ~3 years since bluss created petgraph.

It is reasonable to expect the capacity of a set is not semantically meaningful. With std::collections::HashSet or std::set (in C++), there is a difference between "capacity" and "size"; "size" has semantic meaning while "capacity" is an implementation detail exposed for performance reasons.

It is also reasonable to expect that the capacity/size (ie number of bits not number of ones) of a bit set is semantically meaningful, for example the C++ std library bitset the size is part of the type of the set.

I hear the counter argument @jrraymond , I think it makes sense from the bitset point of view like you said. If the user (like in my case) wants a different semantics, they can implement PartialEq on their wrapping types.

Maybe the doc can just be clearer around this case, but I agree for most users that is irrelevant :D