Tracking Issue for slice::split_at_unchecked() and split_at_mut_unchecked() #76014
Comments
sdroege
added
the
C-tracking-issue
jonas-schievink
added
B-unstable
…ed() These are unsafe variants of the non-unchecked functions and don't do any bounds checking. For the time being these are not public and only a preparation for the following commit. Making it public and stabilization can follow later and be discussed in rust-lang#76014 .
|
This is now merged but not as public API. I think this would be useful to have though, at least the mutable version as it's dealing with raw pointers and it's much harder to use There are probably also some places in |
KodrAus
added
the
Libs-Tracked
|
Why the API is private? If there is no reason, I could make a PR making it public. I've just found myself coping the methods from std, to use them... |
|
It's very strange that this API is both private and unstable with a tracking issue. Was this intentional? |
…r=dtolnay Make `<[T]>::split_at_unchecked` and `<[T]>::split_at_mut_unchecked` public The methods were originally added in rust-lang#75936 (sdroege@30dc32b), but for some reason as private. Nevertheless, the methods have documentation and even a [tracking issue](rust-lang#76014). It's very weird to have a tracking issue for private methods and these methods may be useful outside of the standard library. As such, this PR makes the methods public.
Implement split_array and split_array_mut This implements `[T]::split_array::<const N>() -> (&[T; N], &[T])` and `[T; N]::split_array::<const M>() -> (&[T; M], &[T])` and their mutable equivalents. These are another few “missing” array implementations now that const generics are a thing, similar to rust-lang#74373, rust-lang#75026, etc. Fixes rust-lang#74674. This implements `[T; N]::split_array` returning an array and a slice. Ultimately, this is probably not what we want, we would want the second return value to be an array of length N-M, which will likely be possible with future const generics enhancements. We need to implement the array method now though, to immediately shadow the slice method. This way, when the slice methods get stabilized, calling them on an array will not be automatic through coercion, so we won't have trouble stabilizing the array methods later (cf. into_iter debacle). An unchecked version of `[T]::split_array` could also be added as in rust-lang#76014. This would not be needed for `[T; N]::split_array` as that can be compile-time checked. Edit: actually, since split_at_unchecked is internal-only it could be changed to be split_array-only.
Implement split_array and split_array_mut This implements `[T]::split_array::<const N>() -> (&[T; N], &[T])` and `[T; N]::split_array::<const M>() -> (&[T; M], &[T])` and their mutable equivalents. These are another few “missing” array implementations now that const generics are a thing, similar to rust-lang#74373, rust-lang#75026, etc. Fixes rust-lang#74674. This implements `[T; N]::split_array` returning an array and a slice. Ultimately, this is probably not what we want, we would want the second return value to be an array of length N-M, which will likely be possible with future const generics enhancements. We need to implement the array method now though, to immediately shadow the slice method. This way, when the slice methods get stabilized, calling them on an array will not be automatic through coercion, so we won't have trouble stabilizing the array methods later (cf. into_iter debacle). An unchecked version of `[T]::split_array` could also be added as in rust-lang#76014. This would not be needed for `[T; N]::split_array` as that can be compile-time checked. Edit: actually, since split_at_unchecked is internal-only it could be changed to be split_array-only.
Implement split_array and split_array_mut This implements `[T]::split_array::<const N>() -> (&[T; N], &[T])` and `[T; N]::split_array::<const M>() -> (&[T; M], &[T])` and their mutable equivalents. These are another few “missing” array implementations now that const generics are a thing, similar to rust-lang#74373, rust-lang#75026, etc. Fixes rust-lang#74674. This implements `[T; N]::split_array` returning an array and a slice. Ultimately, this is probably not what we want, we would want the second return value to be an array of length N-M, which will likely be possible with future const generics enhancements. We need to implement the array method now though, to immediately shadow the slice method. This way, when the slice methods get stabilized, calling them on an array will not be automatic through coercion, so we won't have trouble stabilizing the array methods later (cf. into_iter debacle). An unchecked version of `[T]::split_array` could also be added as in rust-lang#76014. This would not be needed for `[T; N]::split_array` as that can be compile-time checked. Edit: actually, since split_at_unchecked is internal-only it could be changed to be split_array-only.
|
The |
|
Also useful would be a |
|
What is left to do to get this stabilized? #75936 was merged just a few days after this issue was created, so just the stabilization PR and docs, or are those done/in-progress? It seems like a pretty straightforward thing to get done, is there anything I can do to help push it along? |
|
I'd also be willing to contribute if that'd help get this stabilized sooner! |
|
If anyone is interested in moving this feature forward (@InsertCreativityHere?), I would suggest submitting a stabilization PR to at least get the ball rolling on discussion. Stabilization just means changing the attributes and writing a good PR message so it's quite easy (see the reference here https://rustc-dev-guide.rust-lang.org/stability.html#stabilizing-a-library-feature).
@sffc for future reference, if you have a proposal then you should submit an ACP (that's just an issue template at this repo: https://github.com/rust-lang/libs-team). Somebody actually did that recently at rust-lang/libs-team#308, and the tracking issue is here #119128 |
m-ou-se
added
the
I-libs-api-nominated
|
@rfcbot merge |
|
Team member @m-ou-se has proposed to merge this. The next step is review by the rest of the tagged team members: No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See this document for info about what commands tagged team members can give me. |
rfcbot
added
proposed-final-comment-period
Amanieu
removed
the
I-libs-api-nominated
rfcbot
added
the
final-comment-period
rfcbot
removed
the
proposed-final-comment-period
|
🔔 This is now entering its final comment period, as per the review above. 🔔 |
rfcbot
added
finished-final-comment-period
|
The final comment period, with a disposition to merge, as per the review above, is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. This will be merged soon. |
Rollup merge of rust-lang#120577 - wutchzone:slice_split_at_unchecked, r=m-ou-se Stabilize slice_split_at_unchecked Greetings! I took the opportunity, and I tried to stabilize the `slice_split_at_unchecked` feature. I followed the guidelines, and I hope everything was done correctly 🤞 . Closes rust-lang#76014
…, r=m-ou-se Stabilize slice_split_at_unchecked Greetings! I took the opportunity, and I tried to stabilize the `slice_split_at_unchecked` feature. I followed the guidelines, and I hope everything was done correctly 🤞 . Closes rust-lang#76014
|
Is anything holding stabilization of this? |
This is a tracking issue for the
slice::split_at_unchecked()andslice::split_at_mut_unchecked()functions.The feature gate for the issue is
#![feature(slice_split_at_unchecked)].API
Steps
Unresolved Questions
slice::get_unchecked()orslice::from_raw_parts()?The text was updated successfully, but these errors were encountered: