-
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
Implement TryFrom<&[T]> for &[T; N] #44764
Conversation
There are many cases where a buffer with a static compile-time size is preferred over a slice with a dynamic size. This allows for performing a checked conversion from &[T] to &[T; N]. This may also lead to compile-time optimizations involving [T; N] such as loop unrolling.
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @BurntSushi (or someone else) soon. If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes. Please see the contribution instructions for more information. |
Thanks for the awesome PR, @nvzqz! We'll wrangle up a top-notch reviewer for you in a short amount of time! |
I'd love to make arrays better, but shouldn't we wait for const generics? |
Is there a reason this would conflict or not be implementable with const generics? Otherwise it seems to leave us in no worse shape than we are now. |
Not that I'm aware of. People have previously been cautious about metadata bloat though. |
This change adds 66 new implementations of |
I haven't been following |
ping @sfackler, mind taking a look at this? |
/// The error type returned when a conversion from a slice to an array fails. | ||
#[unstable(feature = "try_from", issue = "33417")] | ||
#[derive(Debug, Copy, Clone)] | ||
pub struct TryFromSliceError(()); |
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.
This should probably implement Error
in libstd.
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.
Should the Display
implementation also be in libstd or libcore?
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.
See e45e8ab
I'm on board with these existing, but let's see if everyone is okay with more ad-hoc array stuff. @rfcbot fcp merge |
Oops, forgot to libs tag it @rfcbot fcp merge |
Team member @sfackler has proposed to merge this. The next step is review by the rest of the tagged teams: No concerns currently listed. Once these reviewers reach consensus, 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. |
|
I believe that the let values = [1, 2, 3, 4];
let three: &[i32; 3] = values[..3].try_into().unwrap();
// Or even:
let last: &[i32; 2] = values[2..4].try_into().unwrap(); |
In other similar situations like copy_from_slice and clone_from_slice, we require that the lengths match exactly. |
☔ The latest upstream changes (presumably #44174) made this pull request unmergeable. Please resolve the merge conflicts. |
ping @BurntSushi and @aturon for your ticky boxes here! |
If |
|
Is this just waiting on @aturon? It's been 3 weeks now 😕 |
@aturon was out for two weeks, but hopefully should be back now, but he is traveling a bit again this week :) i'll ping him on IRC. |
impl fmt::Display for TryFromSliceError { | ||
#[inline] | ||
fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result { | ||
fmt::Display::fmt(self.__description(), f) |
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.
Why not use the description method from the Error
trait?
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.
Error is declined in libstd, not libcore
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.
Defined* (I'm on mobile)
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.
I see, never mind.
🔔 This is now entering its final comment period, as per the review above. 🔔 |
Egad sorry for the delay! This can now be approved after we've all signed off -- @bors: r+ |
📌 Commit 4c853ad has been approved by |
Implement TryFrom<&[T]> for &[T; N] There are many cases where a buffer with a static compile-time size is preferred over a slice with a dynamic size. This allows for performing a checked conversion from `&[T]` to `&[T; N]`. This may also lead to compile-time optimizations involving `[T; N]` such as loop unrolling. This is my first PR to Rust, so I'm not sure if discussion of this change should happen here or does it need its own RFC? I figured these changes would be a subset of #33417.
☀️ Test successful - status-appveyor, status-travis |
This commit serves to provide the same benefits as PR rust-lang#44764 except for boxes that refer to owned arrays allocated in the heap.
We're missing |
There are many cases where a buffer with a static compile-time size is preferred over a slice with a dynamic size. This allows for performing a checked conversion from
&[T]
to&[T; N]
. This may also lead to compile-time optimizations involving[T; N]
such as loop unrolling.This is my first PR to Rust, so I'm not sure if discussion of this change should happen here or does it need its own RFC? I figured these changes would be a subset of #33417.