Change:
#![feature(rustc_attrs)] #![cfg_attr(test, feature(test))] #![feature(strict_provenance)] <del> #![feature(ptr_const_cast)] </del> use smallvec::SmallVec;

Discussion:
<!-- Thank you for creating a tracking issue! Tracking issues are for tracking a feature from implementation to stabilization. Make sure to include the relevant RFC for the feature if it has one. If the new feature is small, it may be fine to skip the RFC process. In that case, you can use use in your initial implementation PR. The reviewer will ask you to open a tracking issue if they agree your feature can be without an RFC. --Feature gate: This is a tracking issue for methods on pointers for casting constness without changing the type <!-- For most library features, it'd be useful to include a summarized version of the public API. (E.g. just the public function signatures without their doc comments or implementation.) --<!-- For larger features, more steps might be involved. If the feature is changed later, please add those PRs here as well. --- [x] Implementation: [ ] Final comment period (FCP) [ ] Stabilization PR <!-- Once the feature has gone through a few release cycles and there are no unresolved questions left, the feature might be ready for stabilization. If this feature didn't go through the RFC process, a final comment period (FCP) is always needed before stabilization. This works as follows: A library API team member can kick off the stabilization process, at which point the rfcbot will ask all the team members to verify they agree with stabilization. Once enough members agree and there are no concerns, the final comment period begins: this issue will be marked as such and will be listed in the next This Week in Rust newsletter. If no blocking concerns are raised in that period of 10 days, a stabilzation PR can be opened by anyone. --<!-- Include any open questions that need to be answered before the feature can be stabilised. If multiple (unrelated) big questions come up, it can be a good idea to open a separate issue for each, to make it easier to keep track of the discussions. It's useful to link any relevant discussions and conclusions (whether on GitHub, Zulip, or the internals forum) here. ---
I like this function (as it allows a codebase to avoid uses of if they desire). I agree thta could lead to some ambiguity, and seems better to me. It's the most similar to , so having a similar name seems correct.

As noted in the documentation, a method isn't strictly necessary, but could be nice for symmetry's sake.
I'm starting to like naming as it seems to be a bit more readable too. Will try to find the time for a PR. I don't mind anyone else doing it either. It's a trivial change anyway.
Once they're called , I wonder if we should also add a type parameter like the existing method, so you don't have to double up etc. (However, they currently document that as an explicit feature, not changing the type.)
yes, not changing the type is the main point because it protects against refactors. You can already do both with .
Shall we rename these to , and also stabilize them? merge
Team member has proposed to merge this. The next step is review by the rest of the tagged team members: [x] [ ] [x] [x] [x] [x] No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period, with a disposition to merge, as per the , is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. This will be merged soon.