add implementation of Ord for Cell<T> and RefCell<T> where T: Ord

[vadixidav]

Raised this in issue #33305.

[rust-highfive]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @brson (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

[jonas-schievink]

I think these sort of proxy impls for RefCell were omitted intentionally, since they need to borrow the cell, which can cause a panic.

[vadixidav]

It is safe code. Borrow on RefCell already can cause a safe panic. Also, the only other way to get Ord on a RefCell is by making a newtype, which was problematic in some code I was writing where I would have to make newtypes and write tons of boilerplate for about 10 types. Also, it would cause a panic anyways if std was passed some sort of closure or used the Ref from the borrow() function when a RefMut was in existence. There is no way to implement Ord for RefCell in any other way. Also, Cell didn't have any Ord either, despite it not having the borrow issue.

[jonas-schievink]

Of course it's safe, but it might be surprising. I don't think there's any other operator impl in the standard library that can panic.

I would have to make newtypes and write tons of boilerplate for about 10 types.

Why isn't struct OrdRefCell<T> enough? Or did you mean you're only using it for 10 different types?

Also, it would cause a panic anyways if std was passed some sort of closure or used the Ref from the borrow() function

The difference is that the .borrow() would have been written explicitly by the user, while this puts it in the standard library (and not even into a regular method, but into otherwise harmless operators like <).

I don't think it's too much of a hassle to have to write x.borrow() < y.borrow(), but then again I don't know your code so YMMV.

Regarding Cell, maybe that's just an oversight. I don't know.

[vadixidav]

Eq is implemented on RefCell. That will cause the same issue. To be consistent we should add this as well.

[jonas-schievink]

Huh, indeed. In that case, I agree that these should be added for consistency. Same for Cell.

[sfackler]

For historical context: #25744

[alexcrichton]

I'd be fine merging this. This is just extending what we already have with PartialEq and the conclusion of #25744 was that the ergonomic win here is worth it.

[alexcrichton]

The libs team discussed this during triage the other day and the conclusion was to merge. Thanks again for the PR @vadixidav!

@bors: r+ 4dcb637

[bors]

⌛ Testing commit 4dcb637 with merge 992bb13...

[bors]

☀️ Test successful - auto-linux-32-nopt-t, auto-linux-32-opt, auto-linux-32cross-opt, auto-linux-64-cargotest, auto-linux-64-cross-armhf, auto-linux-64-cross-armsf, auto-linux-64-cross-freebsd, auto-linux-64-cross-netbsd, auto-linux-64-debug-opt, auto-linux-64-nopt-t, auto-linux-64-opt, auto-linux-64-opt-mir, auto-linux-64-opt-rustbuild, auto-linux-64-x-android-t, auto-linux-cross-opt, auto-linux-musl-64-opt, auto-mac-32-opt, auto-mac-64-nopt-t, auto-mac-64-opt, auto-mac-64-opt-rustbuild, auto-mac-cross-ios-opt, auto-win-gnu-32-nopt-t, auto-win-gnu-32-opt, auto-win-gnu-32-opt-rustbuild, auto-win-gnu-64-nopt-t, auto-win-gnu-64-opt, auto-win-msvc-32-cross-opt, auto-win-msvc-32-opt, auto-win-msvc-64-cargotest, auto-win-msvc-64-opt, auto-win-msvc-64-opt-mir, auto-win-msvc-64-opt-rustbuild