stabilize core parts of MaybeUninit

[RalfJung]

and deprecate mem::uninitialized in the future (1.40.0). This is part of implementing rust-lang/rfcs#1892.

Also expand the documentation a bit.

This type is currently primarily useful when dealing with partially initialized arrays. In libstd, it is used e.g. in BTreeMap (with some unstable APIs that however can all be replaced, less ergonomically, by stable ones). What we stabilize should also be enough for SmallVec (Cc @bluss).

Making this useful for structs requires rust-lang/rfcs#2582 or a commitment that references to uninitialized data are not insta-UB.

[rust-highfive]

r? @Kimundi

(rust_highfive has picked a reviewer for you, use r? to override)

[Centril]

r? @Centril

[cramertj]

Why not 1.36?

[RalfJung]

This function is widely used so I figured we'd give it some time.

[Centril]

I would suggest 1.38 instead as a middle ground. 1.34.0 seems rather long (~6 months from 1.36).

[RalfJung]

The precedent with #52994 is to keep it future-deprecated for 3 releases, that would be 1.39.

[Centril]

It's looks pretty great overall but here are some things that would be good to improve on.

I'll work up an FCP when I wake up tomorrow :)

[Centril]

Stabilization proposal

I propose that we stabilize the following API:

#[derive(Copy)]pubunionMaybeUninit<T>{uninit:(),value:ManuallyDrop<T>,}impl<T:Copy>CloneforMaybeUninit<T>{ ... }impl<T>MaybeUninit<T>{pubconstfnnew(val:T) -> MaybeUninit<T>{ ...}pubconstfnuninit() -> MaybeUninit<T>{ ...}pubfnzeroed() -> MaybeUninit<T>{ ...}pubfnas_ptr(&self) -> *constT{ ...}pubfnas_mut_ptr(&mutself) -> *mutT{ ...}pubunsafefnassume_init(self) -> T{ ...}}

The proposed interface is minimal yet still useful as noted in the PR description:

This type is currently primarily useful when dealing with partially initialized arrays. In libstd, it is used e.g. in BTreeMap (with some unstable APIs that however can all be replaced, less ergonomically, by stable ones). What we stabilize should also be enough for SmallVec (Cc @bluss).

As the description notes, the API has also been tested inside the standard library and elsewhere.

The name of the type, MaybeUninit, has already gone through the FCP process and the other parts have been extensively bikeshedded. As such, I believe we are ready to commit to this today with more to come eventually.

The documentation for MaybeUninit<T> is already thorough, with more documentation being added in this PR.

A further note: rust-lang/rfcs#2582 has not been accepted yet and therefore we leave in place a warning in the documentation for anyone that tries to rely on those semantics with current surface syntax. Or as the PR description notes:

Making this useful for structs requires rust-lang/rfcs#2582 or a commitment that references to uninitialized data are not insta-UB.

As for the deprecation of mem::uninitialized, I propose that we schedule to deprecate uninitialized in 1.38. The function is widely used, but 3 months on stable should still be ample time to allow people to migrate.

With all that said:

@rfcbot merge

[rfcbot]

Team member @Centril has proposed to merge this. The next step is review by the rest of the tagged team members:

• @Amanieu
• @Centril
• @Kimundi
• @SimonSapin
• @alexcrichton
• @aturon
• @cramertj
• @dtolnay
• @eddyb
• @joshtriplett
• @nikomatsakis
• @pnkfelix
• @scottmcm
• @sfackler
• @withoutboats

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 this document for info about what commands tagged team members can give me.

[Centril]

Small nit; otherwise it looks great.

[withoutboats]

Is there a crater run on how much of the ecosystem currently uses mem::uninitialized?

[Centril]

@withoutboats I don't believe so.

[Centril]

We discussed this briefly on the lang team meeting. Mainly, the subject was the deprecation schedule. We agreed that clear communication was important. We should also try to do a crater run to see when deprecation is most opportune. However, (in my personal view) we can stabilize and tweak the deprecation date later based on data.

[RalfJung]

@bors r=Centril

[bors]

📌 Commit 1916391 has been approved by Centril

[RalfJung]

@bors p=1

[bors]

⌛ Testing commit 1916391 with merge 6dabc5d1c3298e8fede2f41503d30e27e48e6236...

[emilyalbini]

@bors retry

Yielding priority to the stable release.

[SimonSapin]

@pietroalbini By the way, https://github.com/rust-lang/rust/blob/beta/src/bootstrap/channel.rs mentioning 1.35 suggests that 1.36 beta has not been cut yet, is that right? It’d be nice if this PR can make it in.

[RalfJung]

The process says "Promote master to beta (T-2 days, Tuesday)", so I take it if we can land this today we are good?

That was the expectation anyways. ;)

[RalfJung]

@bors p=50

[emilyalbini]

@SimonSapin yep, beta will be cut tomorrow. I'll try to remember to check this PR before cutting it.

[bors]

⌛ Testing commit 1916391 with merge d35181a...

[bors]

☀️ Test successful - checks-travis, status-appveyor
Approved by: Centril
Pushing d35181a to master...