Change:
<!-- 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 making the function . <!-- Include a short description of the feature. --<!-- 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 commenting 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 commenting period (FCP) is always needed before stabilization. This works as follows: A library 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 commenting 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. --- None yet.
This got reverted again by , but hopefully we can re-land it soon.
Sorry, I misread, this feature gate is not affected (but some others are).
Any news on this? I don't see anything holding it back; especially now that transmute itself is const. EDIT: Never mind, I just saw
Since is const-stable nowadays, I think this can be stabilized as well. Feel free to open a PR. :) Cc
I didn't do this before, I am reading the docs for how to do this, and there's an rfcbot final commenting period thing. Should this be done? If yes, how? I probably don't have the rights to do it.
You just need to prepare a PR. I can help get the FCP process started in the PR.

Discussion:
#![feature(const_slice_split_at_mut)] #![feature(const_str_from_utf8_unchecked_mut)] #![feature(const_swap)] <del> #![feature(const_transmute_copy)] </del> #![feature(const_try)] #![feature(const_type_id)] #![feature(const_type_name)]

#[inline] #[must_use] #[stable(feature = "rust1", since = "1.0.0")] <del> #[rustc_const_unstable(feature = "const_transmute_copy", issue = "83165")] </del> <ins> #[rustc_const_stable(feature = "const_transmute_copy", since = "CURRENT_RUSTC_VERSION")] </ins> pub const unsafe fn transmute_copy<Src, Dst>(src: &Src) -> Dst { assert!( size_of::<Src>() >= size_of::<Dst>(),