Add MaybeUninit array transpose impls

[SUPERCILEX]

See discussion in #101179 and #96097. I believe this solution offers the simplest implementation with minimal future API regret. Closes rust-lang/libs-team#110.

@RalfJung mind doing a correctness review?

[rust-highfive]

r? @scottmcm

(rust-highfive has picked a reviewer for you, use r? to override)

[rustbot]

Hey! It looks like you've submitted a new PR for the library teams!

If this PR contains changes to any rust-lang/rust public library APIs then please comment with @rustbot label +T-libs-api -T-libs to tag it appropriately. If this PR contains changes to any unstable APIs please edit the PR description to add a link to the relevant API Change Proposal or create one if you haven't already. If you're unsure where your change falls no worries, just leave it as is and the reviewer will take a look and make a decision to forward on if necessary.

Examples of T-libs-api changes:

• Stabilizing library features
• Introducing insta-stable changes such as new implementations of existing stable traits on existing stable types
• Introducing new or changing existing unstable library APIs (excluding permanently unstable features / features without a tracking issue)
• Changing public documentation in ways that create new stability guarantees
• Changing observable runtime behavior of library APIs

[SUPERCILEX]

@rustbot label +T-libs-api -T-libs

[thomcc]

I'm definitely in favor of adding this, but I think it needs an ACP.

[SUPERCILEX]

@thomcc Sounds good, done: rust-lang/libs-team#110

[SUPERCILEX]

Hmmm, no idea how those failures are related. Will ignore for now.

[RalfJung]

Yeah that's a strange error, can you rebase and force push?

[RalfJung]

The transmutation itself is sound. This is insta-stable though so definitely needs careful T-libs review.

[RalfJung]

Looks good, apart from some nits.

But I can't judge if Into instances are the right way to expose such APIs; I leave that to T-libs.

[SUPERCILEX]

Sweet, thanks for the review! :)

[scottmcm]

impls are insta-stable, so this needs to go to libs-api.

@rustbot label +needs-fcp
r? rust-lang/libs-api

[SUPERCILEX]

r? @scottmcm I think this can go back to you now that these are going through the standard nightly process.

[scottmcm]

suggestion: while this works fine, since none of it can panic, we try in the docs to follow the "pre-pit your peaches" order of things, rather than "forget it afterwards", and consider forget soft-deprecated.

So please update this to something like

    pub fn transpose(self) -> [MaybeUninit<T>; N] {
        // SAFETY: T, ManuallyDrop<T>, and MaybeUninit<T> have the same layout
        unsafe { super::transmute_copy(&ManuallyDrop::new(self)) }
    }

(And ditto for the one below)

[SUPERCILEX]

Oh yeah, that's so much better. Is there a reason forget isn't deprecated? It seems like you could always replace it with let _ = ManuallyDrop::new(foo); (or drop(ManuallyDrop::new(foo));) worse case scenario.

[scottmcm]

Yeah, you can -- in fact that's literally what forget does

rust/library/core/src/mem/mod.rs

Lines 153 to 155 in b8c35ca

	pub const fn forget<T>(t: T) {
	let _ = ManuallyDrop::new(t);
	}

I think it's not deprecated because, unlike mem::uninitialized, there's lots of code that used forget that's still perfectly correct because it only does things (like copy_nonoverlapping) that can't panic.

But maybe it's time to start thinking about it, now that ManuallyDrop has been around for long enough. Or at least a deprecated-in-rust-2.0 for now so it gets picked up by

rust/compiler/rustc_lint_defs/src/builtin.rs

Lines 2243 to 2258 in 9b0a099

	declare_lint! {
	/// The `deprecated_in_future` lint is internal to rustc and should not be
	/// used by user code.
	///
	/// This lint is only enabled in the standard library. It works with the
	/// use of `#[deprecated]` with a `since` field of a version in the future.
	/// This allows something to be marked as deprecated in a future version,
	/// and then this lint will ensure that the item is no longer used in the
	/// standard library. See the [stability documentation] for more details.
	///
	/// [stability documentation]: https://rustc-dev-guide.rust-lang.org/stability.html#deprecated
	pub DEPRECATED_IN_FUTURE,
	Allow,
	"detects use of items that will be deprecated in a future version",
	report_in_external_macro
	}

[scottmcm]

Hmm, maybe not. It looks like mem::forget(guard); is still very common in the library for panic guards, where there's no need to consume them like in the example, and thus the forget phrasing is kinda nice.

But maybe that also just means that the PanicGuard types should have a defuse method or something as part of its API instead of telling people to forget it.

[SUPERCILEX]

Hmmm, yeah I see the appeal for panic guards, but poking around the stdlib I think it's actually pretty hard to understand what's going on unless you know what the guards are for, so maybe encouraging people to write a defuse method or add a comment explaining the weirdness is a good thing. Created #103101.

[scottmcm]

Thanks! These look good for nightly to me.

@bors r+

[bors]

📌 Commit 393434c has been approved by scottmcm

It is now in the queue for this repository.

[bors]

⌛ Testing commit 393434c with merge e928a46...

[RalfJung]

The PR title is outdated now, right?

[SUPERCILEX]

Yup, fixed.

[SimonSapin]

Is transmute_copy(&ManuallyDrop::new(self)) different from transmute(self)?

[scottmcm]

@SimonSapin Yes, because transmute doesn't know that MaybeUninit<[T; N]> and [MaybeUninit<T>; N] are the same size, and thus fails to compile.

EDIT: Fixed! Thanks @thomcc!

[thomcc]

Yes, because transpose...

(I think you mean transmute, and only mention it because it might be pretty confusing with the mistake)