-
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
[WIP] Add From<(Vec<T>, C)>
for BinaryHeap a.k.a. flexible BinaryHeap
#69454
Conversation
(rust_highfive has picked a reviewer for you, use r? to override) |
The job Click to expand the log.
I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
As of 9b1ba2a, stage 0 test From the build error, it looks like |
From<(Vec<T>, C)>
for BinaryHeap a.k.a. flexible BinaryHeap
From<(Vec<T>, C)>
for BinaryHeap a.k.a. flexible BinaryHeap
The job Click to expand the log.
I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
I locally commented out conflicting After that, |
I don't personally think this is something we want. Most users should likely be satisfied with a wrapper struct with a similar structure to what you have here, and something more involved can likely be dealt with by wrapping BinaryHeap itself (e.g., I think implementing this in the ecosystem may be the better option to start with; it would (AFAICT) be instantly a stable implementation detail that the struct has a custom comparator with is a pretty high bar to meet. (To be clear, my opinions are not the library team's who would be responsible for ultimately accepting this. But I believe these are reasonable concerns to have some answer to before bringing it to a wider audience). |
For example: https://crates.io/crates/binary-heap-plus |
Thanks for comments! I actually first wrote So I decided to port I'm OK to record this PR as just a historical attempt and close for now. |
Ah, sorry, I hadn't even made the connection that you were the author of that crate. FWIW, I do think that's nicely done, but I don't see a clear path for it to directly replace the |
It was better for me to mention that first.
|
This PR will
C: Fn(&T, &T) -> Option<Ordering>
to the existingBinaryHeap<T>
.pub struct MaxCmp
which can be used as the defaultC
.binary_heap_max_cmp
From<(Vec<T>, C)>
impl to support genericBinaryHeap<T, C>
creation.binary_heap_from_vec_cmp
T: Ord
bound where possible.The features refer to #38886.
Unresolved questions
Comparator type
I used
C: Fn(&T, &T) -> Option<Ordering>
which is compatible withPartialOrd::partial_cmp()
return type.C: Fn(&T, &T) -> Ordering
is more straightforward but it broke some corner-case test.Should we go with the latter and fix tests instead?
Needs crater run?
While stage 0 unit tests
$ ./x.py test src/liballoc --stage 0
run fine,serde
was failed to build.serde
needs to be patched before it lands?The below in
serde-1.0.99
conflicts with this PR#.https://github.com/serde-rs/serde/blob/192f5cd647dfb67bfd6158e7234c78c95894c071/serde/src/de/impls.rs#L786-L794