Tracking Issue for raw array getters (array_ptr_get)

[yotamofek]

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].

See also:

• Similar methods for raw slices: Tracking Issue for raw slice getters (slice_ptr_get) #74265

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.

Footnotes

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

[Lokathor]

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.

[zdivelbiss]

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

[yotamofek]

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!)

[briansmith]

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.

[zdivelbiss]

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).

[yotamofek]

@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.

[zdivelbiss]

@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?

[yotamofek]

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