Tracking Issue for pointer methods returning MaybeUninit<T>
#75402
Comments
TimDiekmann
added
the
C-tracking-issue
|
A possible concern for stabilization is that these methods will be somewhat redundant if we end up deciding that references do not have to point to valid data -- though maybe reflecting the initialization state is a good idea even in that case? Also it seems likely that some |
…r=RalfJung Add `as_uninit`-like methods to pointer types and unify documentation of `as_ref` methods This adds a convenient method to retrieve a `&(mut) [MaybeUninit<T>]` from slice pointers (`*const [T]`, `*mut [T]`, `NonNull<[T]>`). See also rust-lang/wg-allocators#66 (comment). ~I'll add a tracking issue as soon as it's reviewed and CI passed.~ Tracking Issue: rust-lang#75402 r? @RalfJung
|
Having such cast on pointers rather than references could be useful in situations like in #93653 (although having cast on @RalfJung any good resource explaining why it'd be useful to allow uninitialized references? Anyway, I do like tracking (un)initializedness in type even for documentation value. |
|
For documentation, it is the safety invariant of a type that is most relevant, and those certainly still apply recursively below references. For the validity invariant, see rust-lang/unsafe-code-guidelines#77 for the discussion. Basically, specifying the language becomes a hell of a lot simpler if the validity invariant depends solely on the bit pattern of the value itself, and not on other state of the system such as the current contents of memory. I would argue that directly translates to making life easier for unsafe code authors (as one of the consumers of such a specification). Also generally I think we should require reasons to make something UB, the default should be not-UB. :) |
|
I noticed that However, on I think these methods should take |
|
|
Change `NonNull::as_uninit_*` to take self by value (as opposed to reference), matching primitive pointers. Copied from my comment on [rust-lang#75402](rust-lang#75402 (comment)): > I noticed that `as_uninit_*` on pointers take `self` by value (and pointers are `Copy`), e.g. see [`as_uninit_mut`](https://doc.rust-lang.org/core/primitive.pointer.html#method.as_uninit_mut). > > However, on `NonNull`, these functions take `self` by reference, e.g. see the function with the same name by for `NonNull`: [`as_uninit_mut`](https://doc.rust-lang.org/std/ptr/struct.NonNull.html#method.as_uninit_mut) takes `self` by mutable reference. Even more inconsistent, [`as_uninit_slice_mut`](https://doc.rust-lang.org/std/ptr/struct.NonNull.html#method.as_uninit_slice_mut) returns a mutable reference, but takes `self` by immutable reference. > > I think these methods should take `self` by value for consistency. The returned lifetime is unbounded anyways and not tied to the pointer/NonNull value anyways I realized the change is trivial (if desired) so here I am creating my first PR. I think it's not a breaking change since (it's on nightly and) `NonNull` is `Copy`; all previous usages of these methods taking `self` by reference should continue to compile. However, it might cause warnings to appear on usages of `NonNull::as_uninit_mut`, which used to require the the `NonNull` variable be declared `mut`, but now it's not necessary.
Change `NonNull::as_uninit_*` to take self by value (as opposed to reference), matching primitive pointers. Copied from my comment on [#75402](rust-lang/rust#75402 (comment)): > I noticed that `as_uninit_*` on pointers take `self` by value (and pointers are `Copy`), e.g. see [`as_uninit_mut`](https://doc.rust-lang.org/core/primitive.pointer.html#method.as_uninit_mut). > > However, on `NonNull`, these functions take `self` by reference, e.g. see the function with the same name by for `NonNull`: [`as_uninit_mut`](https://doc.rust-lang.org/std/ptr/struct.NonNull.html#method.as_uninit_mut) takes `self` by mutable reference. Even more inconsistent, [`as_uninit_slice_mut`](https://doc.rust-lang.org/std/ptr/struct.NonNull.html#method.as_uninit_slice_mut) returns a mutable reference, but takes `self` by immutable reference. > > I think these methods should take `self` by value for consistency. The returned lifetime is unbounded anyways and not tied to the pointer/NonNull value anyways I realized the change is trivial (if desired) so here I am creating my first PR. I think it's not a breaking change since (it's on nightly and) `NonNull` is `Copy`; all previous usages of these methods taking `self` by reference should continue to compile. However, it might cause warnings to appear on usages of `NonNull::as_uninit_mut`, which used to require the the `NonNull` variable be declared `mut`, but now it's not necessary.
|
Visiting for T-compiler backlog bonanza @RalfJung 's comments above were somewhat echo'ed by @m-ou-se in the meeting @rustbot label: S-tracking-design-concerns |
rustbot
added
the
S-tracking-design-concerns
move some const fn out of the const_ptr_as_ref feature When a `const fn` is still `#[unstable]`, it should generally use the same feature to track its regular stability and const-stability. Then when that feature moves towards stabilization we can decide whether the const-ness can be stabilized as well, or whether it should be moved into a new feature. Also, functions like `ptr::as_ref` (which returns an `Option<&mut T>`) require `is_null`, which is tricky and blocked on some design concerns (see rust-lang#74939). So move those to the is_null feature gate, as they should be stabilized together with `ptr.is_null()`. Affects rust-lang#91822, rust-lang#122034, rust-lang#75402, rust-lang#74939
move some const fn out of the const_ptr_as_ref feature When a `const fn` is still `#[unstable]`, it should generally use the same feature to track its regular stability and const-stability. Then when that feature moves towards stabilization we can decide whether the const-ness can be stabilized as well, or whether it should be moved into a new feature. Also, functions like `ptr::as_ref` (which returns an `Option<&mut T>`) require `is_null`, which is tricky and blocked on some design concerns (see rust-lang#74939). So move those to the is_null feature gate, as they should be stabilized together with `ptr.is_null()`. Affects rust-lang#91822, rust-lang#122034, rust-lang#75402, rust-lang#74939
Rollup merge of rust-lang#130164 - RalfJung:const_ptr_as_ref, r=dtolnay move some const fn out of the const_ptr_as_ref feature When a `const fn` is still `#[unstable]`, it should generally use the same feature to track its regular stability and const-stability. Then when that feature moves towards stabilization we can decide whether the const-ness can be stabilized as well, or whether it should be moved into a new feature. Also, functions like `ptr::as_ref` (which returns an `Option<&mut T>`) require `is_null`, which is tricky and blocked on some design concerns (see rust-lang#74939). So move those to the is_null feature gate, as they should be stabilized together with `ptr.is_null()`. Affects rust-lang#91822, rust-lang#122034, rust-lang#75402, rust-lang#74939
This is a tracking issue for methods on pointer types returning
MaybeUninit:as_uninit_ref/mutandas_uninit_slice(_mut)on mutable and const raw pointers andNonNull.The feature gate for the issue is
#![feature(ptr_as_uninit)].About tracking issues
Tracking issues are used to record the overall progress of implementation.
They are also uses as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.
Steps
Unresolved Questions
as_uninit_ref_uncheckedorOption::unwrap_uncheckedNonNulltakeself,&self,&mut self? Also see the discussion at ChangeNonNull::as_uninit_*to take self by value (as opposed to reference), matching primitive pointers. #96100.Implementation history
as_uninit-like methods to pointer types and unify documentation ofas_refmethods #75392The text was updated successfully, but these errors were encountered: