Add `MaybeUninit` methods `uninit_array`, `slice_get_ref`, `slice_get_mut` #65580

SimonSapin · 2019-10-18T23:30:06Z

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 · 2019-10-18T23:30:10Z

r? @withoutboats

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

SimonSapin · 2019-10-18T23:30:18Z

CC @rust-lang/libs, @RalfJung

src/libcore/mem/maybe_uninit.rs

Centril · 2019-10-19T05:02:10Z

src/libcore/mem/maybe_uninit.rs

+    #[inline(always)]
+    pub fn uninit_array<const LEN: usize>() -> [Self; LEN] {
+        unsafe {
+            MaybeUninit::<[MaybeUninit<T>; LEN]>::uninit().assume_init()


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 · 2019-10-19T11:07:08Z

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 · 2019-10-19T12:04:41Z

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 · 2019-10-19T12:21:17Z

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 · 2019-10-19T15:53:19Z

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 · 2019-10-19T22:00:08Z

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 · 2019-10-26T03:09:25Z

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

Amanieu · 2019-10-26T11:22:57Z

@bors r+

bors · 2019-10-26T11:22:58Z

📌 Commit 2cb52a628868f0307f5a5da0056760e695cc64c2 has been approved by Amanieu

src/libcore/mem/maybe_uninit.rs

Centril · 2019-10-26T11:59:47Z

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

Centril · 2019-10-30T13:49:03Z

@bors r- p=0 rollup=maybe

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

hdhoang · 2019-11-07T06:15:34Z

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

SimonSapin · 2019-11-07T08:13:54Z

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

Centril · 2019-11-07T08:15:50Z

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

SimonSapin · 2019-11-07T10:58:19Z

Not at all, go ahead!

…_mut`

Co-Authored-By: Mazdak Farrokhzad <[email protected]>

Centril · 2019-11-07T11:06:27Z

@bors r=Amanieu rollup

bors · 2019-11-07T11:06:28Z

📌 Commit 639c4f7 has been approved by Amanieu

…nieu Add `MaybeUninit` methods `uninit_array`, `slice_get_ref`, `slice_get_mut` 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: ```rust 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"); ```

@ghost

Rollup of 8 pull requests Successful merges: - #65554 (Enhance the documentation of BufReader for potential data loss) - #65580 (Add `MaybeUninit` methods `uninit_array`, `slice_get_ref`, `slice_get_mut`) - #66049 (consistent handling of missing sysroot spans) - #66056 (rustc_metadata: Some reorganization of the module structure) - #66123 (No more hidden elements) - #66157 (Improve math log documentation examples) - #66165 (Ignore these tests ,since the called commands doesn't exist in VxWorks) - #66190 (rustc_target: inline abi::FloatTy into abi::Primitive.) Failed merges: - #66188 (`MethodSig` -> `FnSig` & Use it in `ItemKind::Fn`) r? @ghost

bors · 2019-11-08T07:57:37Z

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

This is possible now that inline const blocks are stable; the idea was even mentioned as an alternative when `uninit_array()` was added: <rust-lang#65580 (comment)> > 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];` Const array repetition and inline const blocks are now stable (in the next release), so that circumstance has come to pass, and we no longer have reason to want `uninit_array()` (unless the repeat syntax is too annoying).

This is possible now that inline const blocks are stable; the idea was even mentioned as an alternative when `uninit_array()` was added: <rust-lang#65580 (comment)> > 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];` Const array repetition and inline const blocks are now stable (in the next release), so that circumstance has come to pass, and we no longer have reason to want `uninit_array()` other than convenience. Therefore, let’s evaluate the inconvenience by not using `uninit_array()` in the standard library, before potentially deleting it entirely.

Remove `MaybeUninit::uninit_array()` and replace it with inline const blocks. \[This PR originally contained the changes in rust-lang#125995 too. See edit history for the original PR description.] The documentation of `MaybeUninit::uninit_array()` says: > Note: in a future Rust version this method may become unnecessary when Rust allows [inline const expressions](rust-lang#76001). The example below could then use `let mut buf = [const { MaybeUninit::<u8>::uninit() }; 32];`. The PR adding it also said: <rust-lang#65580 (comment)> > 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];` That time has come to pass — inline const expressions are stable — so `MaybeUninit::uninit_array()` is now unnecessary. The only remaining question is whether it is an important enough *convenience* to keep it around. I believe it is net good to remove this function, on the principle that it is better to compose two orthogonal features (`MaybeUninit` and array construction) than to have a specific function for the specific combination, now that that is possible.

Rollup merge of rust-lang#125082 - kpreid:const-uninit, r=dtolnay Remove `MaybeUninit::uninit_array()` and replace it with inline const blocks. \[This PR originally contained the changes in rust-lang#125995 too. See edit history for the original PR description.] The documentation of `MaybeUninit::uninit_array()` says: > Note: in a future Rust version this method may become unnecessary when Rust allows [inline const expressions](rust-lang#76001). The example below could then use `let mut buf = [const { MaybeUninit::<u8>::uninit() }; 32];`. The PR adding it also said: <rust-lang#65580 (comment)> > 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];` That time has come to pass — inline const expressions are stable — so `MaybeUninit::uninit_array()` is now unnecessary. The only remaining question is whether it is an important enough *convenience* to keep it around. I believe it is net good to remove this function, on the principle that it is better to compose two orthogonal features (`MaybeUninit` and array construction) than to have a specific function for the specific combination, now that that is possible.

rust-highfive assigned withoutboats Oct 18, 2019

rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Oct 18, 2019

bluetech reviewed Oct 19, 2019

View reviewed changes

src/libcore/mem/maybe_uninit.rs Show resolved Hide resolved

Centril reviewed Oct 19, 2019

View reviewed changes

bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Oct 26, 2019

Centril reviewed Oct 26, 2019

View reviewed changes

src/libcore/mem/maybe_uninit.rs Outdated Show resolved Hide resolved

src/libcore/mem/maybe_uninit.rs Outdated Show resolved Hide resolved

bors added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Oct 30, 2019

SimonSapin and others added 3 commits November 7, 2019 12:05

Add MaybeUninit methods uninit_array, slice_get_ref, `slice_get…

1906c6f

…_mut`

Apply docs suggestions from review

05c14bc

Co-Authored-By: Mazdak Farrokhzad <[email protected]>

MaybeUninit::uninit_array docs: better example

639c4f7

Centril force-pushed the maybeuninit-array branch from 2cb52a6 to 639c4f7 Compare November 7, 2019 11:05

bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Nov 7, 2019

Centril mentioned this pull request Nov 7, 2019

Rollup of 4 pull requests #66184

Closed

JohnTitor mentioned this pull request Nov 8, 2019

Rollup of 8 pull requests #66208

Merged

bors merged commit 639c4f7 into rust-lang:master Nov 8, 2019

bors added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Nov 8, 2019

SimonSapin deleted the maybeuninit-array branch November 28, 2019 12:04

joboet mentioned this pull request Jan 11, 2021

Tracking Issue for maybe_uninit_array_assume_init #80908

Closed

6 tasks

clarfonthey mentioned this pull request Apr 16, 2022

Tracking Issue for MaybeUninit methods for arrays #96097

Open

7 tasks

kpreid mentioned this pull request May 13, 2024

Replace uses of MaybeUninit::uninit_array() with inline const blocks. #125082

Merged

Add MaybeUninit methods uninit_array, slice_get_ref, slice_get_mut #65580

Add MaybeUninit methods uninit_array, slice_get_ref, slice_get_mut #65580

Uh oh!

Conversation

SimonSapin commented Oct 18, 2019

Uh oh!

rust-highfive commented Oct 18, 2019

Uh oh!

SimonSapin commented Oct 18, 2019

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Centril Oct 19, 2019

Choose a reason for hiding this comment

Uh oh!

RalfJung commented Oct 19, 2019

Uh oh!

SimonSapin commented Oct 19, 2019

Uh oh!

Amanieu commented Oct 19, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ollie27 commented Oct 19, 2019

Uh oh!

SimonSapin commented Oct 19, 2019

Uh oh!

JohnCSimon commented Oct 26, 2019

Uh oh!

Amanieu commented Oct 26, 2019

Uh oh!

bors commented Oct 26, 2019

Uh oh!

Uh oh!

Uh oh!

Centril commented Oct 26, 2019

Uh oh!

Centril commented Oct 30, 2019

Uh oh!

hdhoang commented Nov 7, 2019

Uh oh!

SimonSapin commented Nov 7, 2019

Uh oh!

Centril commented Nov 7, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

SimonSapin commented Nov 7, 2019

Uh oh!

Centril commented Nov 7, 2019

Uh oh!

bors commented Nov 7, 2019

Uh oh!

bors commented Nov 8, 2019

Uh oh!

Uh oh!

Add `MaybeUninit` methods `uninit_array`, `slice_get_ref`, `slice_get_mut` #65580

Add `MaybeUninit` methods `uninit_array`, `slice_get_ref`, `slice_get_mut` #65580

Amanieu commented Oct 19, 2019 •

edited

Loading

Centril commented Nov 7, 2019 •

edited

Loading