Add MaybeUninit methods uninit_array, slice_get_ref, slice_get_mut

[SimonSapin]

Eventually these will hopefully become the idiomatic way to work with partially-initialized stack buffers.

All methods are unstable. Note that uninit_array takes a type-level const usize parameter, so it is blocked (at least in its current form) on const generics.

Example:

use std::mem::MaybeUninit;

let input = b"Foo";
let f = u8::to_ascii_uppercase;

let mut buffer: [MaybeUninit<u8>; 32] = MaybeUninit::uninit_array();
let vec;
let output = if let Some(buffer) = buffer.get_mut(..input.len()) {
    buffer.iter_mut().zip(input).for_each(|(a, b)| { a.write(f(b)); });
    unsafe { MaybeUninit::slice_get_ref(buffer) }
} else {
    vec = input.iter().map(f).collect::<Vec<u8>>();
    &vec
};

assert_eq!(output, b"FOO");

[rust-highfive]

r? @withoutboats

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

[SimonSapin]

CC @rust-lang/libs, @RalfJung

[Centril]

This is a bit of a bummer. We should be able to use:

[Self::UNINIT; LEN]

here were it not for the fact that we would get "error: array lengths can't depend on generic parameters" (solvable by e.g. allowing _ as the array length -- https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=28015a7e1c5856eef0ee32f4d53206a5).

Can you leave a FIXME for now?

[RalfJung]

The API itself seems reasonable (though of get_ref and friends are renamed, likely the slice methods should, too).

However, I expected to also see something that turns [MaybeUninit<T>; N] into [T; N] -- something like array_assume_init. Why is that not needed?

[SimonSapin]

array_assume_init could certainly be added, but some users may want to avoid it because moving large arrays can get expensive. In theory it’s could compile to a no-op, but today’s optimizer often has trouble eliding redundant copies. (Compare with Box::<[MaybeUninit<_>]>::assume_init which is a pointer cast even without optimizations.) So a possible pattern for large-ish buffers is to create them uninitalized on the stack, then only interact with them through borrows.

[Amanieu]

I see the main use case for these to be I/O functions:

// Returns a (possibly smaller) slice of data that was actually read
fn read(buf: &mut [MaybeUninit<u8>]) -> &[u8] {
    unsafe {
        // I'm ignoring any error checking here
        let len = libc::read(fd, buf.as_mut_ptr() as *mut u8, buf.len());
        MaybeUninit::slice_get_ref(&buf[..len])
    }
}

let mut buf: [MaybeUninit<u8>; 32] = MaybeUninit::uninit_array();
let data = read(&mut buf);

[ollie27]

What's the reason for uninit_array when you can already use [MaybeUninit::<T>::uninit(); N] for T: Copy and with #49147 it should work for all types?

[SimonSapin]

For T: !Copy, given that #49147 is not available on the stable channel yet, let buffer = unsafe { MaybeUninit::<[MaybeUninit<T>; $N]>::uninit().assume_init() } is a somewhat common pattern today. Having in the standard library avoid the unsafe block in user code.

I didn’t realize that #49147 would apply here, but you’re right that if it’s stabilized soon enough maybe it’s not worth having a standard library method that will be replaceable with let buffer = [MaybeUninit::<T>::uninit(); $N];

[JohnCSimon]

Ping from triage
@withoutboats can you please review this PR
cc: @SimonSapin
Thank you!

[Amanieu]

@bors r+

[bors]

📌 Commit 2cb52a628868f0307f5a5da0056760e695cc64c2 has been approved by Amanieu

[Centril]

@bors p=-1 rollup=never until the docs are fixed

[Centril]

@bors r- p=0 rollup=maybe

@SimonSapin Can you please fix the docs so that they are consistent? :) Thanks.

[hdhoang]

ping from triage @SimonSapin, can you address the reviewer's comment? thanks!

[SimonSapin]

This week is rather packed but I’ll get around to it. Sorry for the delays!

[Centril]

@SimonSapin Do you mind if I help out and fix the issue locally and push to your branch?

[SimonSapin]

Not at all, go ahead!

[Centril]

@bors r=Amanieu rollup

[bors]

📌 Commit 639c4f7 has been approved by Amanieu

[bors]

☔ The latest upstream changes (presumably #66208) made this pull request unmergeable. Please resolve the merge conflicts.