Tracking Issue for raw array getters (array_ptr_get) #119834
Description
Activity
- added a commit that references this issue
on Mar 17, 2024 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.
Reacted by Josh Junon, Guillaume E and Zavier Divelbiss+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_arrayis 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 asf(uninit.as_mut_ptr().as_ptr_range().start.cast_init()), if there wereas_ptr_rangeon*{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()andstart_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()andstart_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).
Reacted by Guillaume E@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 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
&Tinto a*Tor 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.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)
Reacted by Zavier DivelbissIt would be nice to have these on
NonNulltoo, as well as theget_unchecked(_mut)function likeslice_ptr_getadds.
Feature gate:
#![feature(array_ptr_get)]This is a tracking issue for
as_(mut_)ptrandas_(mut_)slicemethods on raw array pointers, i.e.*(const/mut) [T; N].See also:
Public API
Steps / History
Unresolved Questions
*(const/mut) Selfreceiver. 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
https://std-dev-guide.rust-lang.org/feature-lifecycle/stabilization.html ↩