Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Comparison semantics may be unexpected #53

Closed
ronnodas opened this issue Jan 24, 2024 · 1 comment
Closed

Comparison semantics may be unexpected #53

ronnodas opened this issue Jan 24, 2024 · 1 comment

Comments

@ronnodas
Copy link
Contributor

As implemented, comparison between BitFlags is not the same as contains and depends on the bit assigned to each variant (explicitly or implicitly via the ordering of the variants). This is needed to implement Ord but may not be the expected semantics of a <= b. It would be nice if this was explained in the documentation.

One could even argue that BitFlags<Enum> should not implement Ord but only PartialOrd (with the semantics a <= b iff b.contains(a)) except maybe if Enum implements Ord.

@meithecatte
Copy link
Owner

I do agree that the impl isn't ideal – the usecase is using BitFlags as (part of) a BTreeMap key, which unfortunately requires full Ord, and precludes any meaningful interpretations for <=. I wish Rust had a way to distinguish "meaningful comparison" from BTreeMap's "has an arbitrary ordering" requirement.

I'd gladly merge a PR that clarifies this in the docs, though!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants