Skip to content

feat: add get_disjoint_mut #149

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

Merged
merged 4 commits into from
May 20, 2025
Merged

Conversation

cmrschwarz
Copy link
Contributor

Adds a get_disjoint_mut function similar to the ones on std::slice, std::collections::HashMap or even crates like indexmap. I think its fair to say that the ecosystem is standardizing on this mechanism.

I figured that there was no point in mirroring the more complicated API from [T]::get_disjoint_mut, as this crate cannot return slices of elemens anyways due to the Entry wrapper enum.

I therefore implemented the simpler version as precedented by hasmap and indexmap.

@cmrschwarz cmrschwarz changed the title Get disjoint mut feat: add get_disjoint_mut Apr 25, 2025
@cmrschwarz
Copy link
Contributor Author

cmrschwarz commented Apr 25, 2025

Sorry for missing the low msrv. I added a slab_no_const_generics cfg similar to the slab_no_const_vec_new we already have.
That should fix the problem.

@cmrschwarz cmrschwarz force-pushed the get_disjoint_mut branch 2 times, most recently from 3ccb96e to 1fc6fee Compare April 25, 2025 17:51
@cmrschwarz
Copy link
Contributor Author

cmrschwarz commented Apr 25, 2025

Hmm, this is trickier than I thought.

It seems like on 1.31 we get an error despite the code being cfg'ed out,
presumably because the parser of that version does not understand const in a generic argument list.

I think I have a workaround by moving the implementation to a separate file which is not included on old rust versions.

I'm very sorry for the repeated CI runs, I now tested this using cargo hack locally so we should be good.

@cmrschwarz
Copy link
Contributor Author

cmrschwarz commented Apr 27, 2025

Hmm, #150 removed the build script that this relied on.

Since we are in the process of bumping MSRV anyways, would you consider bumping slightly further to MSRV 1.51 for const generics?

Similar reasoning applies to it, it was released over 4 years ago (March 25, 2021),
and is available in Debian stable (rustc on Debian bookworm is 1.63.0).
The top ten reverse dependencies all have higher MSRVs according to #150 (comment)

If this is acceptable I will gladly update this PR.

@Darksonn
Copy link
Contributor

@paolobarbolini @taiki-e thoughts?

@taiki-e
Copy link
Member

taiki-e commented Apr 28, 2025

MSRV bump to 1.51 is okay.

@cmrschwarz
Copy link
Contributor Author

Awesome. The PR is rebased now.

@cmrschwarz
Copy link
Contributor Author

Any updates on this?

Copy link
Contributor

@Darksonn Darksonn left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks.

@Darksonn Darksonn merged commit f801afe into tokio-rs:master May 20, 2025
6 checks passed
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 this pull request may close these issues.

3 participants