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;letmut buffer:[MaybeUninit<u8>;32] = MaybeUninit::uninit_array();let vec;let output = ifletSome(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 readfnread(buf:&mut[MaybeUninit<u8>]) -> &[u8]{unsafe{// I'm ignoring any error checking herelet len = libc::read(fd, buf.as_mut_ptr()as*mutu8, buf.len());MaybeUninit::slice_get_ref(&buf[..len])}}letmut 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.