-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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 array_methods
#76118
Comments
Just for the protocol, I plan to add the following methods in the near future:
(discussions about the usefulness of those method should be had in the dedicated PR threads and not here) |
…-to-array, r=Mark-Simulacrum Add `[T; N]::as_[mut_]slice` Part of me trying to populate arrays with a couple of basic useful methods, like slices already have. The ability to add methods to arrays were added in rust-lang#75212. Tracking issue: rust-lang#76118 This adds: ```rust impl<T, const N: usize> [T; N] { pub fn as_slice(&self) -> &[T]; pub fn as_mut_slice(&mut self) -> &mut [T]; } ``` These methods are like the ones on `std::array::FixedSizeArray` and in the crate `arraytools`.
@LukasKalbertodt I have opened PR #79451 for |
…ds, r=dtolnay Add `[T; N]::each_ref` and `[T; N]::each_mut` This PR adds the methods `each_ref` and `each_mut` to `[T; N]`. The ability to add methods to arrays was added in rust-lang#75212. These two methods are particularly useful with `map` which was also added in that PR. Tracking issue: rust-lang#76118 ```rust impl<T, const N: usize> [T; N] { pub fn each_ref(&self) -> [&T; N]; pub fn each_mut(&mut self) -> [&mut T; N]; } ```
With regards to stabilization I think I think they are much more useful than the others in this tracking issue. These are already common methods for existing data types so it's not a new API. I sometimes find myself running into cases where For example // io::Read does something like this
trait Trait {}
impl Trait for &[u8] {}
impl<T: Trait + ?Sized> Trait for &mut T {}
fn takes_trait(t: impl Trait) {}
fn main() {
let mut arr = [0, 1, 2, 3];
// currently
takes_trait(&mut &arr[..]);
// with `.as_slice()` its nice and clear
takes_trait(&mut arr.as_slice());
// can't use deref coercion in this case
takes_trait(&mut &arr);
// ^^^^^^^^^ the trait `Trait` is not implemented for `&[u8; 4]`
} |
I agree with @rossmacarthur and would like to propose stabilizing |
Partial stabilization is up: #88353 |
…oshtriplett Partially stabilize `array_methods` This stabilizes `<[T; N]>::as_slice` and `<[T; N]>::as_mut_slice`, which is forms part of the `array_methods` feature: rust-lang#76118. This also makes `<[T; N]>::as_slice` const due to its trivial nature.
…oshtriplett Partially stabilize `array_methods` This stabilizes `<[T; N]>::as_slice` and `<[T; N]>::as_mut_slice`, which is forms part of the `array_methods` feature: rust-lang#76118. This also makes `<[T; N]>::as_slice` const due to its trivial nature.
Hm, I didn't think too much about it when posting the last reply. I guess you're right about |
Are there any further objections over the current names, or are these ready to stabilize? |
Can these be made |
Technically For instance, with const fn each_ref<T, const N: usize>(arr: &[T; N]) -> [&T; N] {
array![i => &arr[i]; N]
} |
Curious why provide
This would avoid intermediate arrays of almost-always-pointless references, would save a method call in almost all cases, and likely be easier to optimize for. Also, |
Noteworthy: |
@LukasKalbertodt Is there anything specific blocking stabilization of |
@pierzchalski There is an open PR that stabilizes these methods as is. It seems like the current names are generally accepted now. In the PR there are no objections, but @dead-claudia raised an objection in this thread above. I would disagree though: having three versions of every method makes for a really bloated and awkward API. Yes, it's not uncommon in Rust to have these three versions of the same method, but usually only if there isn't a better way. In the Regarding optimization: yep, I heard that array methods tend to optimize non-optimally in some cases. That's unfortunate of course. But this is just a consequences of how the optimization pipeline works right now; the API does not inherently make proper optimizations impossible! Many people have proposed some kind of constant length iterator with lazy evaluation, but I have no idea if there is any progress on that. Thus, I personally don't think these are arguments against |
@rust-lang/libs-api: impl [T; N] {
pub fn each_ref(&self) -> [&T; N];
pub fn each_mut(&mut self) -> [&mut T; N];
} I suggested this naming in #75490 (review) and provided further rationale for it in #75490 (review). I continue to think these are good names. The naming discussion above has reached a stopping point without any traction behind any better set of names, in my opinion. Aside from naming, a point to consider was whether these functions are amenable enough to optimization. See #76118 (comment) with a response in #76118 (comment). In #80094 (comment) we removed Is let strings = ["Ferris".to_string(), "♥".to_string(), "Rust".to_string()];
let is_ascii = strings.each_ref().map(|s| s.is_ascii());
assert_eq!(is_ascii, [true, false, true]);
// We can still access the original array: it has not been moved. But notice that rust/compiler/rustc_lint/src/context.rs Line 209 in d7229c4
Alternatives: something like |
Team member @dtolnay 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. |
Any news about this? |
🔔 This is now entering its final comment period, as per the review above. 🔔 |
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. |
…, r=dtolnay stabilise array methods Closes rust-lang#76118 Stabilises the remaining array methods FCP is yet to be carried out for this There wasn't a clear consensus on the naming, but all the other alternatives had some flaws as discussed in the tracking issue and there was a silence on this issue for a year
Rollup merge of rust-lang#103522 - Dylan-DPC:76118/array-methods-stab, r=dtolnay stabilise array methods Closes rust-lang#76118 Stabilises the remaining array methods FCP is yet to be carried out for this There wasn't a clear consensus on the naming, but all the other alternatives had some flaws as discussed in the tracking issue and there was a silence on this issue for a year
Now that `array::each_mut` has stabilized (rust-lang/rust#76118), we'll be able to get rid of this unsafe block! We'll have to wait for Rust 1.77 to release this though (and maybe a bit longer if we want to preserve MSRV).
This is a tracking issue for a couple of basic methods on arrays. The feature gate for the issue is
#![feature(array_methods)]
. Currently, this includes the following methods:as_slice
,as_mut_slice
Add[T; N]::as_[mut_]slice
#76120each_ref
,each_mut
Add[T; N]::each_ref
and[T; N]::each_mut
#75490Note: these methods were all collected under the same
array_methods
feature name as I suspect many (often small) methods to be added to array in the near future. Creating a new feature and tracking issue for each seems overkill. We can still split off some methods into dedicated features later, if required.About tracking issues
Tracking issues are used to record the overall progress of implementation.
They are also uses as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.
Steps
Unresolved Questions
each_ref
andeach_mut
or change it to something else? Alternatives:each_as_ref
/each_as_mut
,as_refs
/as_mut_refs
. See PR Add[T; N]::each_ref
and[T; N]::each_mut
#75490 for the name discussion.The text was updated successfully, but these errors were encountered: