Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.
Sign upSets should not impl Ord, and should impl PartialOrd differently (?) #16570
Comments
This comment has been minimized.
This comment has been minimized.
|
CC @aturon |
This comment has been minimized.
This comment has been minimized.
|
Discuss thread with these points listed: Perhaps as part of the collections restructuring support for multiple orderings will have to be invented somehow. |
This comment has been minimized.
This comment has been minimized.
|
I think all containers should implement ordering as a lexicographic comparison. There are separate methods for checking for a subset / superset already, and we would lose the nice |
thestinger
added
the
A-libs
label
Aug 18, 2014
This comment has been minimized.
This comment has been minimized.
|
@thestinger Lexicographic comparisons are crazy for set types because sets are unordered and the only natural ordering used on them is subset inclusion. For ordered containers, you're right, they make sense (and set inclusion doesn't). |
This comment has been minimized.
This comment has been minimized.
|
The sole reason |
This comment has been minimized.
This comment has been minimized.
|
Ok, thanks. I was misunderstanding the implied semantics of - |
This comment has been minimized.
This comment has been minimized.
|
Alright, satisfied that this has been addressed: Lexicographic ordering is useful and standard. |
Gankro commentedAug 18, 2014
Currently, sets that have some notion of an ordering over their elements (TreeSet and BitvSet, at least) implement Ord in terms of the lexicographic ordering of their contents. However, as @apoelstra notes in #16559 it may be more natural for sets to be ordered by inclusion. That is,
a<=bifa subseteq b.However, there is no total ordering over set inclusion. It instead forms a diamond-shaped DAG. Thus, Sets would not implement Ord under this scheme. In fact, almost all pairs of sets would have
cmpyieldNone, which makes it a not-very-useful operator for generic comparison. Further, inclusion relationships are already provided by the actual Set api.