Tracking Issue for pointer methods returning `MaybeUninit<T>`

[TimDiekmann]

This is a tracking issue for methods on pointer types returning MaybeUninit: as_uninit_ref/mut and as_uninit_slice(_mut) on mutable and const raw pointers and NonNull.
The feature gate for the issue is #![feature(ptr_as_uninit)].

About tracking issues

Tracking issues are used to record the overall progress of implementation.
They are also uses as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.

Steps

• Merge Implementation (cc @rust-lang/T-libs, cc @RalfJung)
• Adjust documentation (see instructions on rustc-dev-guide)
• Stabilization PR (see instructions on rustc-dev-guide)

Unresolved Questions

• Currently, there is no unchecked non-null version for raw pointers without pointer casts. Either we want as_uninit_ref_unchecked or Option::unwrap_unchecked
• Should these operations on NonNull take self, &self, &mut self? Also see the discussion at Change NonNull::as_uninit_* to take self by value (as opposed to reference), matching primitive pointers. #96100.

Implementation history

• Initial implementation: Add as_uninit-like methods to pointer types and unify documentation of as_ref methods #75392

[RalfJung]

A possible concern for stabilization is that these methods will be somewhat redundant if we end up deciding that references do not have to point to valid data -- though maybe reflecting the initialization state is a good idea even in that case? Also it seems likely that some T will not allow uninitialized references, i.e., there is demand for making &! uninhabited.

[Kixunil]

Having such cast on pointers rather than references could be useful in situations like in #93653 (although having cast on Box is even better in that case).

@RalfJung any good resource explaining why it'd be useful to allow uninitialized references? Anyway, I do like tracking (un)initializedness in type even for documentation value.

[RalfJung]

For documentation, it is the safety invariant of a type that is most relevant, and those certainly still apply recursively below references.

For the validity invariant, see rust-lang/unsafe-code-guidelines#77 for the discussion. Basically, specifying the language becomes a hell of a lot simpler if the validity invariant depends solely on the bit pattern of the value itself, and not on other state of the system such as the current contents of memory. I would argue that directly translates to making life easier for unsafe code authors (as one of the consumers of such a specification). Also generally I think we should require reasons to make something UB, the default should be not-UB. :)

[Raekye]

I noticed that as_uninit_* on pointers take self by value (and pointers are Copy), e.g. see as_uninit_mut.

However, on NonNull, these functions take self by reference, e.g. see the function with the same name by for NonNull: as_uninit_mut takes self by mutable reference. Even more inconsistent, as_uninit_slice_mut returns a mutable reference, but takes self by immutable reference.

I think these methods should take self by value for consistency. The returned lifetime is unbounded anyways and not tied to the pointer/NonNull value anyways

[RalfJung]

NonNull::as_ref takes &self. It would seem odd for NonNull::as_uninit_ref to diverge from that?

[pnkfelix]

Visiting for T-compiler backlog bonanza

@RalfJung 's comments above were somewhat echo'ed by @m-ou-se in the meeting

@rustbot label: S-tracking-design-concerns