scottmcm

Thanks for working on this, Oli! I'm really excited 🎉

Thanks for the PR! You'll need to [file an ACP](https://github.com/rust-lang/libs-team/issues/new/choose) to get a libs-api second before we add a new unstable API, as described in .

FWIW, it looks like the unwrap_unchecked compiles well here:

Right, `assume_init` means "assume initialized *as a `T`*", not just "the bits were set" -- otherwise `MaybeUninit::zeroed` would make no sense. And yes, `MaybeUninit` holds `sizeof(T)` bytes that may or...

> Happy to open another FCP, but it sounds like there's a general preference for consolidating all the MaybeUninit changes? Whatever libs-api says is best is what you should do...

Hmm, I suppose could add an inherent `assume_init` method on `[MaybeUninit; N]` now that it's much easier to add inherent methods to built-in types -- that's just as easy to...

Given that we have https://rust-lang.github.io/rfcs/2316-safe-unsafe-trait-methods.html and https://rust-lang.github.io/rfcs/3245-refined-impls.html, I think a feature-gated way to allow putting `const fn` in otherwise non-const `impl`s and a feature-gated way to allow consuming those refined...

I could certainly imagine FCPing the calling of `eq`/`ne`s in `const` for certain types as a temporary measure, since it's already possible (for different reasons) on primitives. It reminds me...

Pondering: is there a reasonable way we could have a takes-`NonNull` version of `from_raw_parts` (and the `_mut` one)? If so, that one could be the one without the check for...

@Amanieu I think it would depend on quantifying the impact. If it usually ends up optimizing out, as it does in the godbolt in https://github.com/rust-lang/libs-team/issues/350#issuecomment-1983189027, then it might be feasible...