MaybeUninit<T> could be Copy for all T

[Diggsey]

At the moment it only implements Copy when T: Copy, but there's no memory-safety reason for it not to always be Copy.

[ExpHP]

I do agree it sounds safe, but perhaps the lack of this serves as a useful lint.

E.g. somebody could do this:

let place = MaybeUninit::<Vec<()>>::uninit();

place.write(vec![]);

// because they're calling "clone", user might think this is safe;
// but in reality, the same vec is read twice.

let vec_1 = unsafe { place.clone().assume_init() };
let vec_2 = unsafe { place.clone().assume_init() };

[Diggsey]

True, but then we probably need another way to make a non-Copy type Copy.

[nagisa]

The example above could be reproduced even without Clone:

let place = MaybeUninit::<Vec<()>>::uninit();
place.write(vec![]);
// implicit Copy
let vec_1 = unsafe { place.assume_init() };
// Boom.
let vec_2 = unsafe { place.assume_init() };

@Diggsey what’s your use-case that’s not served by the APIs currently available?

[Diggsey]

It came up whilst I was looking at ways to get slotmap to work with non-Copy types on stable rust, although that's not a particularly compelling use-case. Mostly it's just a missing escape hatch. We have:

• UnsafeCell for making the immutable, mutable
• MaybeUninit for making the initialised, uninitialised
• unsafe impl Send for making the unsendable, sendable
• unsafe impl Sync for making the not-thread-safe, thread-safe

But there is no escape hatch for making non-Copy data Copy.

[RalfJung]

True, but then we probably need another way to make a non-Copy type Copy.

There was talk about an unsafe impl Copy in the context of #25053.

[cuviper]

Maybe there could be an explicit method to copy MaybeUninit contents?

impl<T> MaybeUninit<T> {
    fn copy(&self) -> Self {
        unsafe { ptr::read(self) }
    }
}

[RalfJung]

@cuviper you mean something like this?

EDIT: Ah, no you meant it should return a MaybeUninit<T>.
Given that this does not actually help for the stated motivation of "unsafely asserting that a type is Copy", I am not sure what that would achieve.

[cuviper]

It wouldn't literally be Copy, but this would still be an "escape hatch" to copy the thing. I don't know if that's sufficient for what slotmap wants, and of course they can do the same ptr::read "copy" anyway.

[Diggsey]

Yeah, the issue is not with actually being able to do a memcpy on the type - that is easy enough. The goal is to be able to use in generic contexts which have a Copy bound.

[timvermeulen]

Ran into this today when I tried to use <[MaybeUninit<T>]>::copy_within.