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

Make Box comparisons independent of allocator choice #241

Closed
gootorov opened this issue Jun 18, 2023 · 1 comment
Closed

Make Box comparisons independent of allocator choice #241

gootorov opened this issue Jun 18, 2023 · 1 comment
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

Comparing Boxs that are allocated by different allocators via PartialEq or PartialOrd is not currently possible.

Motivating examples or use cases

  • It is consistent with PartialEq<Vec<U, A2>> for Vec<T, A1>.
  • I'm writing a library that uses a specific allocator internally. For tests, I'd like to be able to declaratively define data that is expected, and compare it with data that I got. Resorting to Deref<Target = T> and comparing individual fields may be very tedious in cases when the data in question contains several layers of types internally, and especially enums.

Solution sketch

See PR: rust-lang/rust#112628

Alternatives

  • Compare Boxs via Deref<Target = T>.
  • Make sure to use the same allocator everywhere.
@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
@m-ou-se
Copy link
Member

m-ou-se commented Jun 27, 2023

We discussed this briefly in the libs-api meeting. This is fine. Since this doesn't affect the stable API (as Boxes with a custom allocator are unstable), this doesn't need to go through FCP.

@m-ou-se m-ou-se closed this as completed Jun 27, 2023
@Amanieu Amanieu added the ACP-accepted API Change Proposal is accepted (seconded with no objections) label Jun 27, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
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
Development

No branches or pull requests

3 participants