Add inherent versions of MaybeUninit methods for slices by clarfonthey · Pull Request #129259 · rust-lang/rust

clarfonthey · 2024-08-18T23:57:03Z

This is my attempt to un-stall #63569 and #79995, by creating methods that mirror the existing MaybeUninit API:

impl<T>MaybeUninit<T>{pubfnwrite(&mutself,value:T) -> &mutT;pubfnas_bytes(&self) -> &[MaybeUninit<u8>];pubfnas_bytes_mut(&mutself) -> &mut[MaybeUninit<u8>];pubunsafefnassume_init_drop(&mutself);pubunsafefnassume_init_ref(&self) -> &T;pubunsafefnassume_init_mut(&mutself) -> &mutT;}

Adding these APIs:

impl<T>[MaybeUninit<T>]{// replacing copy_from_slice; renamed to avoid conflictpubfnwrite_copy_of_slice(&mutself,value:&[T]) -> &mut[T]whereT:Copy;// replacing clone_from_slice; renamed to avoid conflictpubfnwrite_clone_of_slice(&mutself,value:&[T]) -> &mut[T]whereT:Clone;// identical to non-slice versions; no conflictpubfnas_bytes(&self) -> &[MaybeUninit<u8>];pubfnas_bytes_mut(&mutself) -> &mut[MaybeUninit<u8>];pubunsafefnassume_init_drop(&mutself);pubunsafefnassume_init_ref(&self) -> &[T];pubunsafefnassume_init_mut(&mutself) -> &mut[T];}

Since the assume_init methods are identical to those on non-slices, they feel pretty natural. The main issue with the write methods is naming, as discussed in #79995 among other places. My rationale:

The term "write" should be in them somewhere, to mirror the other API, and this pretty much automatically makes them not collide with any other inherent slice methods.
I chose write_clone_of_slice and write_copy_of_slice since clone and copy are being used as objects here, whereas they're being used as actions in clone_from_slice and copy_from_slice.

The final "weird" thing I've done in this PR is remove a link to Vec<T> from assume_init_drop (both copies, since they're effectively copied docs), since there's no good way to link to Vec for something that can occur both on the page for std/primitive.slice.html and std/vec/struct.Vec.html, since the code here lives in libcore and can't use intra-doc-linking to mention Vec. (see: #121436)

The reason why this method shows up both on Vec<T> and [T] is because the [T] docs are automatically inlined on Vec<T>'s page, since it implements Deref. It's unfortunate that rustdoc doesn't have a way of dealing with this at the moment, but it is what it is, and it's a reasonable compromise for now.

rustbot · 2024-08-18T23:57:11Z

r? @tgross35

rustbot has assigned @tgross35.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

tgross35 · 2024-08-19T00:46:32Z

The implementation looks pretty reasonable to me, but as this is an API decision:

r? libs-api

Is the intent here to replace the existing copy_from_slice and clone_from_slice? If so, those should be removed.

clarfonthey · 2024-08-19T04:58:58Z

I decided to not delete them since so many people are using these methods, but I can deprecate them depending on what people think is best.

Amanieu · 2024-11-26T19:44:17Z

We discussed this in the libs-api meeting. We're happy with these changes, but we would also like to see similar changes for the fill (#117428) and as_bytes (#93092) methods so that all slice-related methods are turned into inherent methods. Note that fill will need to be renamed since it conflicts with the generic fill method on slices (perhaps fill_init?).

Also, the old methods on MaybeUninit should be removed (in a separate PR) so that we don't have duplicate methods that do the same thing.

tgross35 · 2024-12-19T22:18:51Z

Based on the above it seems like there are a few updates needed here.

@rustbot author

tgross35 · 2025-01-08T21:56:39Z

@clarfonthey any chance you are willing to reconsider moving fill changes to another PR? I don't think there is any reason that change needs to happen at the same time.

Just asking because I'd like to start using this new API :)

clarfonthey · 2025-01-08T22:43:05Z

I mean, if you're cool merging this as-is without the fill methods, I'm fine splitting it. Just want to clarify which methods should be left in and which are left out.

tgross35 · 2025-01-08T22:49:09Z

Specifically the changes fill -> write_filled, fill_with -> write_with, fill_from -> write_iter, since the names are the only things not okayed by someone from libs-api at #129259 (comment). So everything except those three are 👍 from me.

clarfonthey · 2025-01-12T05:04:08Z

Rebased and locally tested, but will wait for CI to pass before calling this officially ready. Moved the second half of the PR to #135394.

clarfonthey · 2025-01-12T09:22:04Z

Should be ready to merge!

tgross35 · 2025-01-12T10:05:00Z

🎉

@bors r+

bors · 2025-01-12T10:05:04Z

📌 Commit e37daf0 has been approved by tgross35

It is now in the queue for this repository.

…iaskrgr Rollup of 6 pull requests Successful merges: - rust-lang#129259 (Add inherent versions of MaybeUninit methods for slices) - rust-lang#135374 (Suggest typo fix when trait path expression is typo'ed) - rust-lang#135377 (Make MIR cleanup for functions with impossible predicates into a real MIR pass) - rust-lang#135378 (Remove a bunch of diagnostic stashing that doesn't do anything) - rust-lang#135397 (compiletest: add erroneous variant to `string_enum`s conversions error) - rust-lang#135398 (add more crash tests) r? `@ghost` `@rustbot` modify labels: rollup

Rollup merge of rust-lang#129259 - clarfonthey:maybe_uninit_slices, r=tgross35 Add inherent versions of MaybeUninit methods for slices This is my attempt to un-stall rust-lang#63569 and rust-lang#79995, by creating methods that mirror the existing `MaybeUninit` API: ```rust impl<T> MaybeUninit<T> { pub fn write(&mut self, value: T) -> &mut T; pub fn as_bytes(&self) -> &[MaybeUninit<u8>]; pub fn as_bytes_mut(&mut self) -> &mut [MaybeUninit<u8>]; pub unsafe fn assume_init_drop(&mut self); pub unsafe fn assume_init_ref(&self) -> &T; pub unsafe fn assume_init_mut(&mut self) -> &mut T; } ``` Adding these APIs: ```rust impl<T> [MaybeUninit<T>] { // replacing copy_from_slice; renamed to avoid conflict pub fn write_copy_of_slice(&mut self, value: &[T]) -> &mut [T] where T: Copy; // replacing clone_from_slice; renamed to avoid conflict pub fn write_clone_of_slice(&mut self, value: &[T]) -> &mut [T] where T: Clone; // identical to non-slice versions; no conflict pub fn as_bytes(&self) -> &[MaybeUninit<u8>]; pub fn as_bytes_mut(&mut self) -> &mut [MaybeUninit<u8>]; pub unsafe fn assume_init_drop(&mut self); pub unsafe fn assume_init_ref(&self) -> &[T]; pub unsafe fn assume_init_mut(&mut self) -> &mut [T]; } ``` Since the `assume_init` methods are identical to those on non-slices, they feel pretty natural. The main issue with the write methods is naming, as discussed in rust-lang#79995 among other places. My rationale: * The term "write" should be in them somewhere, to mirror the other API, and this pretty much automatically makes them not collide with any other inherent slice methods. * I chose `write_clone_of_slice` and `write_copy_of_slice` since `clone` and `copy` are being used as objects here, whereas they're being used as actions in `clone_from_slice` and `copy_from_slice`. The final "weird" thing I've done in this PR is remove a link to `Vec<T>` from `assume_init_drop` (both copies, since they're effectively copied docs), since there's no good way to link to `Vec` for something that can occur both on the page for `std/primitive.slice.html` and `std/vec/struct.Vec.html`, since the code here lives in libcore and can't use intra-doc-linking to mention `Vec`. (see: rust-lang#121436) The reason why this method shows up both on `Vec<T>` and `[T]` is because the `[T]` docs are automatically inlined on `Vec<T>`'s page, since it implements `Deref`. It's unfortunate that rustdoc doesn't have a way of dealing with this at the moment, but it is what it is, and it's a reasonable compromise for now.

…iaskrgr Rollup of 6 pull requests Successful merges: - rust-lang#129259 (Add inherent versions of MaybeUninit methods for slices) - rust-lang#135374 (Suggest typo fix when trait path expression is typo'ed) - rust-lang#135377 (Make MIR cleanup for functions with impossible predicates into a real MIR pass) - rust-lang#135378 (Remove a bunch of diagnostic stashing that doesn't do anything) - rust-lang#135397 (compiletest: add erroneous variant to `string_enum`s conversions error) - rust-lang#135398 (add more crash tests) r? `@ghost` `@rustbot` modify labels: rollup

…r=tgross35 `MaybeUninit` inherent slice methods part 2 These were moved out of rust-lang#129259 since they require additional libs-api approval. Tracking issue: rust-lang#117428. New API surface: ```rust impl<T> [MaybeUninit<T>] { // replacing fill; renamed to avoid conflict pub fn write_filled(&mut self, value: T) -> &mut [T] where T: Clone; // replacing fill_with; renamed to avoid conflict pub fn write_with<F>(&mut self, value: F) -> &mut [T] where F: FnMut() -> T; // renamed to remove "fill" terminology, since this is closer to the write_*_of_slice methods pub fn write_iter<I>(&mut self, iter: I) -> (&mut [T], &mut Self) where I: Iterator<Item = T>; } ``` Relevant motivation for these methods; see rust-lang#129259 for earlier methods' motiviations. * I chose `write_filled` since `filled` is being used as an object here, whereas it's being used as an action in `fill`. * I chose `write_with` instead of `write_filled_with` since it's shorter and still matches well. * I chose `write_iter` because it feels completely different from the fill methods, and still has the intent clear. In all of the methods, it felt appropriate to ensure that they contained `write` to clarify that they are effectively just special ways of doing `MaybeUninit::write` for each element of a slice. Tracking issue: rust-lang#117428 r? libs-api

Rollup merge of rust-lang#135394 - clarfonthey:uninit-slices-part-2, r=tgross35 `MaybeUninit` inherent slice methods part 2 These were moved out of rust-lang#129259 since they require additional libs-api approval. Tracking issue: rust-lang#117428. New API surface: ```rust impl<T> [MaybeUninit<T>] { // replacing fill; renamed to avoid conflict pub fn write_filled(&mut self, value: T) -> &mut [T] where T: Clone; // replacing fill_with; renamed to avoid conflict pub fn write_with<F>(&mut self, value: F) -> &mut [T] where F: FnMut() -> T; // renamed to remove "fill" terminology, since this is closer to the write_*_of_slice methods pub fn write_iter<I>(&mut self, iter: I) -> (&mut [T], &mut Self) where I: Iterator<Item = T>; } ``` Relevant motivation for these methods; see rust-lang#129259 for earlier methods' motiviations. * I chose `write_filled` since `filled` is being used as an object here, whereas it's being used as an action in `fill`. * I chose `write_with` instead of `write_filled_with` since it's shorter and still matches well. * I chose `write_iter` because it feels completely different from the fill methods, and still has the intent clear. In all of the methods, it felt appropriate to ensure that they contained `write` to clarify that they are effectively just special ways of doing `MaybeUninit::write` for each element of a slice. Tracking issue: rust-lang#117428 r? libs-api

…r=tgross35 `MaybeUninit` inherent slice methods part 2 These were moved out of rust-lang#129259 since they require additional libs-api approval. Tracking issue: rust-lang#117428. New API surface: ```rust impl<T> [MaybeUninit<T>] { // replacing fill; renamed to avoid conflict pub fn write_filled(&mut self, value: T) -> &mut [T] where T: Clone; // replacing fill_with; renamed to avoid conflict pub fn write_with<F>(&mut self, value: F) -> &mut [T] where F: FnMut() -> T; // renamed to remove "fill" terminology, since this is closer to the write_*_of_slice methods pub fn write_iter<I>(&mut self, iter: I) -> (&mut [T], &mut Self) where I: Iterator<Item = T>; } ``` Relevant motivation for these methods; see rust-lang#129259 for earlier methods' motiviations. * I chose `write_filled` since `filled` is being used as an object here, whereas it's being used as an action in `fill`. * I chose `write_with` instead of `write_filled_with` since it's shorter and still matches well. * I chose `write_iter` because it feels completely different from the fill methods, and still has the intent clear. In all of the methods, it felt appropriate to ensure that they contained `write` to clarify that they are effectively just special ways of doing `MaybeUninit::write` for each element of a slice. Tracking issue: rust-lang#117428 r? libs-api

rustbot assigned tgross35 Aug 18, 2024

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-libs Relevant to the library team, which will review and decide on the PR/issue. labels Aug 18, 2024

clarfonthey force-pushed the maybe_uninit_slices branch from a88bac8 to b3cf03fCompare August 19, 2024 00:01