Tracking Issue for maybe_uninit_write_slice #79995
Comments
This comment has been minimized.
This comment has been minimized.
rustbot
added
A-raw-pointers
KodrAus
added
the
Libs-Tracked
|
These functions are great additions to the But if may open the bikeshed, should be renamed to |
This seems like a great reason to name these methods |
|
is it possible to add this as methods on |
|
@drmeepster what are the plans on getting this stabilized? |
|
I'm pretty interested in seeing this stabilized as well. |
|
I think it just needs an ACP and approval. |
|
Regarding the naming, I also think they should be called |
Then why is the api so different? |
Rename MaybeUninit::write_slice A step to push rust-lang#79995 forward. rust-lang/libs-team#122 also suggested to make them inherent methods, but they can't be — they'd conflict with slice's regular methods.
|
It's not possible to implement these methods as inherent methods on rust-lang/libs-team#122 suggested renaming to standard names, and there's a precedent for using "static" methods to avoid conflicts (e.g. @beepster4096 Could you update the issue description? |
…=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.
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.
|
As of #129259 these are now: impl<T> [MaybeUninit<T>] {
pub fn write_copy_of_slice(&mut self, value: &[T]) -> &mut [T] where T: Copy;
pub fn write_clone_of_slice(&mut self, value: &[T]) -> &mut [T] where T: Clone;
}Worth updating the description for this. |
Feature gate:
#![feature(maybe_uninit_write_slice)]This is a tracking issue for
MaybeUninit::copy_from_sliceandMaybeUninit::clone_from_slice.These methods are the equivalents of
[T]::copy_from_sliceand[T]::clone_from_slicefor uninitialized slices.Public API
Steps / History
Unresolved Questions
copy/clone_from_slice?copy_from_sliceandclone_from_slicein Rename MaybeUninit::write_slice #116385write_copy_of_sliceandwrite_clone_of_slicein Add inherent versions of MaybeUninit methods for slices #129259The text was updated successfully, but these errors were encountered: