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.

Sign up for GitHub

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

Jump to bottom

Make PartialOrd for Vec allocator independent #240

Closed
gootorov opened this issue Jun 18, 2023 · 3 comments
Closed

Make PartialOrd for Vec allocator independent #240

gootorov opened this issue Jun 18, 2023 · 3 comments
Labels
ACP-accepted API Change Proposal is accepted (seconded with no objections) api-change-proposal A proposal to add or alter unstable APIs in the standard libraries T-libs-api

Comments

@gootorov
Copy link

Proposal

Problem statement

PartialOrd cannot currently be used on vectors allocated with different allocators.

Motivating examples or use cases

  • It is consistent with PartialEq<Vec<U, A2>> for Vec<T, A1>.
  • Writing tests for/using data structures that are parameterized by an allocator may be tedious due to the fact that an underlying vector cannot be compared with different allocators.

Solution sketch

See PR: rust-lang/rust#112632

Alternatives

Compare underlying slices via Deref<Target = [T]>.
@gootorov gootorov added api-change-proposal A proposal to add or alter unstable APIs in the standard libraries T-libs-api labels Jun 18, 2023
@gootorov gootorov mentioned this issue Jun 18, 2023
Merged
@dtolnay
Copy link
Member

dtolnay commented Jun 18, 2023

Seems good to me.

Let's do a libs-api team FCP on your PR, since this would need to be instantly stable.

@dtolnay dtolnay added the ACP-accepted API Change Proposal is accepted (seconded with no objections) label Jun 18, 2023
@dtolnay dtolnay closed this as completed Jun 18, 2023
@thomcc
Copy link
Member

thomcc commented Jun 18, 2023 •
edited
Loading

It's not insta-stable because Allocator isn't stable (FCP seems fine to me either way, just pointing it out).

@dtolnay
Copy link
Member

dtolnay commented Jun 18, 2023

You are right, good call.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
ACP-accepted API Change Proposal is accepted (seconded with no objections) api-change-proposal A proposal to add or alter unstable APIs in the standard libraries T-libs-api
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@thomcc @dtolnay @gootorov