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

Clarify Ord's requirement: what is needed for sort-order #8071

Closed
omasanori opened this issue Jul 27, 2013 · 6 comments
Closed

Clarify Ord's requirement: what is needed for sort-order #8071

omasanori opened this issue Jul 27, 2013 · 6 comments

Comments

@omasanori
Copy link
Contributor

AFAIK Ord is a trait "for values that can be compared for a sort-order" (quoted from doc) and is distinguished from total ordering (TotalOrd). Sometimes it seems to be regarded as partial ordering. (cf. @cmr's comment at #7765.)

However, some sort algorithms assume that x ~ z if x ~ y and y ~ z. (a ~ b here means !(a < b) && !(a > b). this relation is called equivalent or incomparable.) Without the assumption, in worst case O(N^2) comparison is needed to sort N elements. Strict partial ordering with this assumption is called strict weak ordering.

I think it is necessary to clarify what we require to impls for Ord: partial ordering (probably minimum requirement), weak ordering, or something else.

See also: #8360

@omasanori
Copy link
Contributor Author

In #8357, @thestinger told me Container could use the default methods of Ord if T is a totally ordered set.
I didn't come up with the case weak ordering is not enough but I agree that total order is enough.

@bluss
Copy link
Member

bluss commented Aug 8, 2013

I think we need Eq + Ord for lexical order for sequences and tuples. I'm testing out some code

https://gist.github.com/anonymous/17b1b418713e676d5cea

I think we need to, for every Ord relation R, do

`[x, ..xs] R [y, ..ys]  =  if x != y { x R y } else { xs R ys }`

which means, find the first nonequal element pair, and their comparison is the result.

@omasanori
Copy link
Contributor Author

@blake2-ppc Great. I think Eq is not necessary if R satisfies transitivity of incomparability (the assumption in sammary), though.

https://gist.github.com/omasanori/6188497

@huonw
Copy link
Member

huonw commented Nov 24, 2013

Triage: still unclear; #10320 is one possible solution (just make Ord a total ordering and remove the separate TotalOrd trait); it's not clear that #10320 will be accepted so I'm leaving this open for now (if it isn't accepted then we will need to define the type of ordering).

@thestinger
Copy link
Contributor

#12517 can cover this as part of renaming and fixing the incorrect documentation and incorrect generic code.

@omasanori
Copy link
Contributor Author

Thank you.

flip1995 pushed a commit to flip1995/rust that referenced this issue Dec 17, 2021
…dnet

Add new lint to warn when #[must_use] attribute should be used on a method

This lint is somewhat similar to https://rust-lang.github.io/rust-clippy/master/index.html#must_use_candidate but also different: it emits a warning by default and only targets methods (so not functions nor associated functions).

Someone suggested it to me after this tweet: https://twitter.com/m_ou_se/status/1466439813230477312

I think it would reduce the number of cases of API misuses quite a lot.

What do you think?

---

changelog: Added new [`return_self_not_must_use`] lint
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

Successfully merging a pull request may close this issue.

4 participants