-
Notifications
You must be signed in to change notification settings - Fork 13k
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
Add array
lang item and [T; N]::map(f: FnMut(T) -> S)
#75212
Conversation
6c237b8
to
e961a6e
Compare
53846a6
to
664e456
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The implementation looks good to me, leaving this to:
- @rust-lang/lang for the new lang item
array
which allows us to implement methods for[T; N]
. - @rust-lang/libs for the new unstable method
fn array::map
.
Looks like this may lead to |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me. I wonder if the doc changes requires doc team to review. CC @jyn514
I don't think we want to implement We do want to implement |
@pickfire ah I'm not sure if |
☀️ Test successful - checks-actions, checks-azure |
I can't find one use case for this in my codebase :-( |
Mm, one case that is particularly useful to me is in numerical computing and performing vectorized operations with fixed size arrays. In this case, it's nice to have a method that retains the size of the array but allows performing some operation on each item in the inner type. I would keep it in mind when looking to operate on something that is a known size at compile that must be transmuted into something that is the same size. With that said, it's not useful for a lot of cases, because I imagine that if the code is not performance sensitive and/or must be dynamically allocated, it'll just use |
@leonardo-m Given how annoying to use arrays have historically been, I'm not that surprised. This is one of those things that gets more useful as new things that produce arrays start showing up -- for example, from the array_chunks(_mut) iterators introduced in #74373 and #75021. |
In my Nightly-based codebase I have probably few thousand arrays, tiny ones, small ones, and larger boxed ones. And currently in about 100% of the case I don't want to create a new array from another one, but read the contents of an array or but mutate an existing array. |
…-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`.
It is not Monadic. That would be more like mapping from elements intro arrays and then concatenating them as the result |
Added [T; N]::zip() This is my first PR to rust so I hope I have done everything right, or at least close :) --- This is PR adds the array method `[T; N]::zip()` which, in my mind, is a natural extension to rust-lang#75212. My implementation of `zip()` is mostly just a modified copy-paste of `map()`. Should I keep the comments? Also am I right in assuming there should be no way for the `for`-loop to panic, thus no need for the dropguard seen in the `map()`-function? The doc comment is in a similar way a slightly modified copy paste of [`Iterator::zip()`](https://doc.rust-lang.org/beta/std/iter/trait.Iterator.html#method.zip) `@jplatte` mentioned in [rust-lang#75490](rust-lang#75490 (comment)) `zip_with()`, > zip and zip_with seem like they would be useful :) is this something I should add (assuming there is interest for this PR at all :))
Added [T; N]::zip() This is my first PR to rust so I hope I have done everything right, or at least close :) --- This is PR adds the array method `[T; N]::zip()` which, in my mind, is a natural extension to rust-lang#75212. My implementation of `zip()` is mostly just a modified copy-paste of `map()`. Should I keep the comments? Also am I right in assuming there should be no way for the `for`-loop to panic, thus no need for the dropguard seen in the `map()`-function? The doc comment is in a similar way a slightly modified copy paste of [`Iterator::zip()`](https://doc.rust-lang.org/beta/std/iter/trait.Iterator.html#method.zip) ``@jplatte`` mentioned in [rust-lang#75490](rust-lang#75490 (comment)) `zip_with()`, > zip and zip_with seem like they would be useful :) is this something I should add (assuming there is interest for this PR at all :))
Added [T; N]::zip() This is my first PR to rust so I hope I have done everything right, or at least close :) --- This is PR adds the array method `[T; N]::zip()` which, in my mind, is a natural extension to rust-lang#75212. My implementation of `zip()` is mostly just a modified copy-paste of `map()`. Should I keep the comments? Also am I right in assuming there should be no way for the `for`-loop to panic, thus no need for the dropguard seen in the `map()`-function? The doc comment is in a similar way a slightly modified copy paste of [`Iterator::zip()`](https://doc.rust-lang.org/beta/std/iter/trait.Iterator.html#method.zip) ```@jplatte``` mentioned in [rust-lang#75490](rust-lang#75490 (comment)) `zip_with()`, > zip and zip_with seem like they would be useful :) is this something I should add (assuming there is interest for this PR at all :))
Added [T; N]::zip() This is my first PR to rust so I hope I have done everything right, or at least close :) --- This is PR adds the array method `[T; N]::zip()` which, in my mind, is a natural extension to rust-lang#75212. My implementation of `zip()` is mostly just a modified copy-paste of `map()`. Should I keep the comments? Also am I right in assuming there should be no way for the `for`-loop to panic, thus no need for the dropguard seen in the `map()`-function? The doc comment is in a similar way a slightly modified copy paste of [`Iterator::zip()`](https://doc.rust-lang.org/beta/std/iter/trait.Iterator.html#method.zip) `@jplatte` mentioned in [rust-lang#75490](rust-lang#75490 (comment)) `zip_with()`, > zip and zip_with seem like they would be useful :) is this something I should add (assuming there is interest for this PR at all :))
…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]; } ```
This introduces an
array
lang item so functions can be defined on top of[T; N]
. This was previously not done because const-generics was not complete enough to allow for this. Now it is in a state that is usable enough to start adding functions.The function added is a monadic (I think?) map from
[T; N] -> [S; N]
. Until transmute can function on arrays, it also allocates an extra temporary array, but this can be removed at some point.r? @lcnr