-
Notifications
You must be signed in to change notification settings - Fork 12.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Tracking Issue for raw slice getters (slice_ptr_get) #74265
Comments
#74679 is a potential blocker for this. |
With #75152, the allocator trait started making use of this. |
Especially with impl<T> NonNull<[T]> {
#[inline]
fn as_mut_ptr(self) -> *mut T {
self.as_non_null_ptr().as_ptr()
}
} If we want this I'd make a PR. |
Seems reasonable to me -- @Amanieu what do you think? |
An alternative name would be |
I don't particularly care for the name bikeshed but I agree that this method would be useful. |
This comment has been minimized.
This comment has been minimized.
…alfJung Add `as_mut_ptr` to `NonNull<[T]>` Adds `as_mut_ptr` to shortcut converting a `NonNull<[T]>` to `*mut T` as proposed in rust-lang#74265 (comment). r? @RalfJung
While using these methods for an upcoming PR, I noticed one thing: there is no const-to-mut coercion for raw pointers (at least not for slices, or maybe method lookup just is unable to use it), so one has to use I wonder if it would make sense to just not have the |
There’s discussion here about adding general I would personally appreciate e.g. some mention to |
These methods are needed to work around the problem described in #99437. Though interestingly, to preserve the full semantics of the original code but fix the aliasing problems, we would want bounds-checked getters on raw slices. |
@steffahn these methods could be named
|
Has there been any progress? It appears all required work is done? This feature will be useful in adding safety |
The API docs for
This is too strong, right? |
"dereferenceable" generally means "points to memory that is inbounds of an allocation". However, these functions take references, so it is indeed UB to call them when there are aliasing conflicts: |
That's surprising; in Rust API documentation, of a pointer, I'd expect it to mean "it is legal to convert this pointer into a reference".
Are we talking about the same functions? rust/library/core/src/ptr/const_ptr.rs Line 1693 in 0ea7ddc
which rust/library/core/src/slice/index.rs Line 238 in 0ea7ddc
I don't see a single reference being accepted, constructed or manipulated at any stage here. |
Sorry, I thought you meant
No, that's not what it means. It's not "referenceable" after all, it's "dereferenceable", referring to the dereference operator |
I think this has been sitting around long enough, clearly a fix for #73987 will not magically materialize. And even with #73987 unresolved, as long as we don't let users write arbitrary-self methods on raw pointers, we can still change the autoref behavior later to use raw pointers when that is enough. So while these methods might have a footgun, they are still better than the status quo. So I propose we move towards stabilizing the raw pointer part of this. (I am less sure about the @rust-lang/types are you aware of anything that would block stabilizing a function that uses a raw slice pointer self type? (AFAIK these would be the first stable functions that do that.) |
#71146 (comment) applies to this feature as well |
This happened to come up in a libs-api meeting. We want to note that stabilization of this feature will likely be blocked on the impl [T] {
fn as_mut_ptr(*const Self) -> *mut T
} |
Yeah I was about to ask, given @joshtriplett's reply here, what the implications are for this feature. However, I think we should really offer some way to work with raw slice pointers. The current situation is pretty unfortunate and nothing has improved for many years. If we can't stabilize this as-is, does @rust-lang/libs-api have any alternatives we could pursue? |
Well, part of the issue is that similar methods have been proposed for array pointers. We'd either have to duplicate them or see what kind of deref-like coercions self types will provide. |
So far, Rust has largely avoided coercions on raw pointers. That's pretty orthogonal to arbitrary-self-types, so I don't expect rust-lang/rfcs#3519 to change that. So another T-lang RFC would be needed to have such coercions on raw ptr methods I think. |
Add as_(mut_)ptr and as_(mut_)slice to raw array pointers Hey, first time contributing to the standard libraries so not completely sure about the process. These functions are complementary to the ones being added in rust-lang#74265 . I found them missing on array pointers. See also: - ACP: rust-lang/libs-team#321 - Tracking issue: rust-lang#119834
Add as_(mut_)ptr and as_(mut_)slice to raw array pointers Hey, first time contributing to the standard libraries so not completely sure about the process. These functions are complementary to the ones being added in rust-lang#74265 . I found them missing on array pointers. See also: - ACP: rust-lang/libs-team#321 - Tracking issue: rust-lang#119834
Rollup merge of rust-lang#119411 - yotamofek:array-ptr-get, r=Nilstrieb Add as_(mut_)ptr and as_(mut_)slice to raw array pointers Hey, first time contributing to the standard libraries so not completely sure about the process. These functions are complementary to the ones being added in rust-lang#74265 . I found them missing on array pointers. See also: - ACP: rust-lang/libs-team#321 - Tracking issue: rust-lang#119834
Is there any interest in implementing a method that does perform bounds checking, while still operating on pointers rather than references? |
That would make sense to me, yeah. I am not in t-libs-api though, so this should probably go through an ACP. |
I ran into an issue with this. |
Would love to have |
This is a tracking issue for indexing methods on raw slices:
get_unchecked(_mut)
andas_(mut_/non_null_)ptr
on raw slices (mutable and const raw pointers andNonNull
).The feature gate for the issue is
#![feature(slice_ptr_get)]
.Public API
History / Steps
NonNull::as_mut_ptr
: Addas_mut_ptr
toNonNull<[T]>
#75248Open questions
arbitrary_self_types
(Arbitrary self types v2 rfcs#3519)The text was updated successfully, but these errors were encountered: