Tracking Issue for raw array getters (array_ptr_get)

Feature gate: #![feature(array_ptr_get)]

This is a tracking issue for as_(mut_)ptr and as_(mut_)slice methods on raw array pointers, i.e. *(const/mut) [T; N].

Public API

impl<T, const N: usize> *mut [T; N] {
    pub fn as_mut_ptr(self) -> *mut T {}
    pub fn as_mut_slice(self) -> *mut [T] {}
}

impl<T, const N: usize> *const [T; N] {
    pub const fn as_ptr(self) -> *const T {}
    pub const fn as_slice(self) -> *const [T] {}
}

Steps / History

ACP: as_(mut_)ptr and as_(mut_)slice methods on raw array pointers libs-team#321
Implementation: Add as_(mut_)ptr and as_(mut_)slice to raw array pointers #119411
Final comment period (FCP)¹
Stabilization PR

Unresolved Questions

If arbitrary_self_types (Arbitrary self types v2 rfcs#3519) is accepted, these methods may be changed to have a *(const/mut) Self receiver. Also, if a deref-like coercion mechanism is added (specifically, *[T; N] -> *[T], similar to the non-raw counterparts), these methods might become redundant.

https://std-dev-guide.rust-lang.org/feature-lifecycle/stabilization.html ↩

Rollup merge of rust-lang#119411 - yotamofek:array-ptr-get, r=Nilstrieb

Unrolled build for rust-lang#119411

Hey so has it been long enough without problems to move for an FCP on this? It seems pretty cut and dry at this point, they do one obvious thing.

+1, this is pretty straightforward, a FCP would be great for this.

As the one who proposed these methods, I'd love to see them stabilized. But I don't think the unresolved questions have been resolved. Esp. regarding this part of the arbitrary self types RFC: https://github.com/rust-lang/rfcs/blob/master/text/3519-arbitrary-self-types-v2.md#enable-for-raw-pointers-or-weak-or-nonnull
Having raw pointers as receivers seems to be something that will be considered in the future, and seeing as how these unstable methods are pretty easy to imitate, I don't believe that stabilizing them right now is a good idea.

(Having said that, I'm in no way a part of the libs team or any other team, if someone with my authority figures that these should be stabilized, that'll be great!)

Consider:

let mut uninit = MaybeUninit::<[T; N]>::uninit();
// many lines
f(uninit.as_mut_ptr().cast::<T>())

With this proposed API, the last line would get rewritten to:

f(uninit.as_mut_ptr().as_mut_ptr())

It's hardly clear what's happening there. In general, the naming of these functions doesn't accurately capture that we're casting from an array type to the array's element type. The lack of symmetry with cast_array is unfortunate. Especially, this new API would be frequently used when interfacing with FFI code that accepts pointers to arrays/slices as a pointer to the first element. Perhaps such code is better written as f(uninit.as_mut_ptr().as_ptr_range().start.cast_init()), if there were as_ptr_range on *{const|mut} [T; N] like there is for slices.

I understand the desire to match the naming for the analogous methods on slices; I think such matching could be better achieved by using a new name for both, perhaps eventually deprecating the one for slices. I think the as_ptr_range() API suggests a good alternative names: start_ptr() and start_ptr_mut(). This would get across very clearly the idea that we're casting a pointer to an array to a pointer to its first element.

I understand the desire to match the naming for the analogous methods on slices; I think such matching could be better achieved by using a new name for both, perhaps eventually deprecating the one for slices. I think the as_ptr_range() API suggests a good alternative names: start_ptr() and start_ptr_mut(). This would get across very clearly the idea that we're casting a pointer to an array to a pointer to its first element.

I agree that your example is somewhat confusing without some sort of IDE to parse what exactly is happening, and it's an unfortunate naming convention to have started with for slices. However, I believe that's outside scope here, and would be better achieved by a separate RFC or issue, that fully encapsulates the problem, and what potential solutions might be. I would be willing to work with you to raise such an issue, or you can create it on your own.

For now, I think this feature is useful, matches other APIs, and is worth entering a FCP. A lot of these features get stuck in the bike-shedding phase, I don't think that's worth the hassle here (given continuity with other APIs).

@briansmith

@briansmith Personally, I like the start_ptr[_mut]() convention. (but yeah, that would warrant a wider reaching change)

For now, I think this feature is useful, matches other APIs, and is worth entering a FCP. A lot of these features get stuck in the bike-shedding phase, I don't think that's worth the hassle here (given continuity with other APIs).

@zdivelbiss you seem to be ignoring the unresolved questions. Bike-shedding is not what's stopping this from being stabilized.

@yotamofek

@yotamofek Ah, you're right, I didn't read the rest of the context before replying. I've crossed-through that statement in my reply.

Also, if a deref-like coercion mechanism is added (specifically, *[T; N] -> *[T], similar to the non-raw counterparts), these methods might become redundant.

In regards to this, are you referring to the impl<T, const N: usize> From<[T; N]> for [T] (or whatever the actual implementation signature is, accounting for references) implementation that allows the above conversion for reference arrays to slices?

No, I'm talking about a coercion mechanism, like how you can coerce a &T into a *T or a &[T; N] into a &[T] (in certain cases). These don't actually go through any traits.
That would obviate the feature tracked here, since you could directly use the slice methods instead of needing array-specific ones.
Actually, it might also prove problematic in terms of method shadowing and stuff, which is probably why the array-specific functions will only ever get stabilized if it's been decided that there is never going to be a ptr-slice to ptr-array coercion mechanism.

https://doc.rust-lang.org/nomicon/coercions.html

Basically this but for pointers: https://doc.rust-lang.org/reference/type-coercions.html#r-coerce.unsize.slice

Thank you for the link, I wasn't aware that implicit coercion existed!

I'm not sure about whether there's plans to add functionality for implicit coercion between the pointer-type counterparts of arrays and slices. Do you have any links to discussions that've happened about it, or is it just a thought you had considered, given the existing coercion behavior?

Additionally, in regards to:

If arbitrary_self_types (rust-lang/rfcs#3519) is accepted, these methods may be changed to have a *(const/mut) Self receiver.

It seems that PR has been merged. Admittedly I don't fully understand how that relates to this feature, but given its been merged, does it make sense to implement it here as you've suggested you might?

My previous comment mentions this part of the RFC. I'll specifically point you to this quote:

This is discussed in the next section, but overall has been judged to be too complicated for now.

(emphasis is in the original text)

Re: the possible future coercion I mentioned, you can see it was brought up as part of the ACP: rust-lang/libs-team#321 (comment)

It would be nice to have these on NonNull too, as well as the get_unchecked(_mut) function like slice_ptr_get adds.

Navigation Menu

Repository navigation

Tracking Issue for raw array getters (array_ptr_get) #119834

Public API

Steps / History

Unresolved Questions

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Tracking Issue for raw array getters (array_ptr_get) #119834

Description

Public API

Steps / History

Unresolved Questions

Footnotes

Activity

Lokathor commented on Dec 15, 2024

zdivelbiss commented on Jul 16, 2025

yotamofek commented on Jul 16, 2025

briansmith commented on Jul 30, 2025

zdivelbiss commented on Jul 30, 2025

yotamofek commented on Jul 31, 2025

zdivelbiss commented on Jul 31, 2025

yotamofek commented on Jul 31, 2025

yotamofek commented on Jul 31, 2025

zdivelbiss commented on Jul 31, 2025

yotamofek commented on Jul 31, 2025

krsnik02 commented on Feb 20, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions