-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
require a total ordering for Eq
and Ord
#12435
Conversation
How about types not providing strict total ordering in |
I opened an issue about floating point types: #12434, and I don't think there are other problems. |
AFAIK For reference: |
@thestinger thanks for pushing on this. |
Does this also make the built in comparison operators for floats a total ordering? |
Rust requires a total ordering for the @brson: No, I haven't touched the floating point implementations yet. At the moment it's just an incorrect implementation, but since @omasanori: If Semantic Versioning is unable to provide a basic guarantee like |
* Requirements: | ||
* | ||
* `a != b` returns the same value as `!(a == b)` | ||
* `a == a` is true |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we put "(reflexive)" "(symmetric)" and "(transitive)" for the three properties below here (since that's the jargon for each of them).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I'll add in the properties in addition to the examples. This isn't a very exhaustive list of requirements anyway, but at least it gets the point across!
Floating point types don't actually satisfy the C++ weak total ordering definition required by |
@omasanori: Could we just leave out build metadata as a whole? It seems optional, and that'd be an easy way out of the problem. |
I'm sorry, I removed a comment accidentally. What I said was the problem is in build metadata. @thestinger Probably we can. Semver doesn't define equality, so it will be OK. |
Cool, this is very similar to what I had in mind. One thing I was wondering about is why the default method is |
@pcwalton: It would be nice to define lt, gt, le, ge and cmp in a cycle to allow implementing only one of the methods and then add something like a lint to warn if at least one is not implemented. At the moment I'm just doing an override of |
|
A total ordering is assumed and required for most generic functions making use of these traits. The `cmp` method also provides a boost in efficiency for sorting sequence types or storing them in a tree set/map since otherwise two passes would often be required. The standard hardware comparison operators for floats do not implement a total order. However, IEEE754 does define an alternate total ordering. Fixing this is now issue #12434 and doesn't need to stand in the way of a sane comparison module. Traits like `PartialEq` and `PartialOrd` could exist, but will never permit a sane implementation. A type implementing `Eq` would be expected to automatically implement `PartialEq` but floating point types have *two* comparison definitions available. I don't think these would see much usage anyway, because there are even alternate definitions of functions as simple as `min`, `max` and `clamp` for floats. Closes #5283 Closes #8071 Closes #10320
I am not interested in playing politics anymore so I have no intention to try to land this. |
…eykril [editors/vscode] cleaer status bar bg color / command when server status returns to OK fixes rust-lang#12433
don't lint [`mixed_attributes_style`] when mixing docs and other attrs add test files for issue rust-lang#12436 move [`mixed_attributes_style`] to `LateLintPass` to enable global `allow` stop [`mixed_attributes_style`] from linting on different attributes add `@compile-flags` to [`mixed_attributes_style`]'s test; turns out not linting in test mod is not a FN. Apply suggestions from code review Co-authored-by: Timo <[email protected]> move [`mixed_attributes_style`] to late pass and stop it from linting on different kind of attributes
don't lint [`mixed_attributes_style`] when mixing docs and other attrs fixes: rust-lang#12435 fixes: rust-lang#12436 fixes: rust-lang#12530 --- changelog: don't lint [`mixed_attributes_style`] when mixing different kind of attrs; and move it to late pass;
don't lint [`mixed_attributes_style`] when mixing docs and other attrs fixes: rust-lang#12435 fixes: rust-lang#12436 fixes: rust-lang#12530 --- changelog: don't lint [`mixed_attributes_style`] when mixing different kind of attrs; and move it to late pass;
don't lint [`mixed_attributes_style`] when mixing docs and other attrs fixes: rust-lang#12435 fixes: rust-lang#12436 fixes: rust-lang#12530 --- changelog: don't lint [`mixed_attributes_style`] when mixing different kind of attrs; and move it to late pass;
A total ordering is assumed and required for most generic functions
making use of these traits. The
cmp
method also provides a boost inefficiency for sorting sequence types or storing them in a tree set/map
since otherwise two passes would often be required.
The standard hardware comparison operators for floats do not implement a
total order. However, IEEE754 does define an alternate total ordering.
Fixing this is now issue #12434 and doesn't need to stand in the way of
a sane comparison module.
Traits like
PartialEq
andPartialOrd
could exist, but will neverpermit a sane implementation. A type implementing
Eq
would be expectedto automatically implement
PartialEq
but floating point types havetwo comparison definitions available. I don't think these would see
much usage anyway, because there are even alternate definitions of
functions as simple as
min
,max
andclamp
for floats.Closes #5283
Closes #8071
Closes #10320