Skip to content
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

Merged
merged 8 commits into from
Nov 1, 2017
Merged

Implement TryFrom<&[T]> for &[T; N] #44764

merged 8 commits into from
Nov 1, 2017

Conversation

nvzqz
Copy link
Contributor

@nvzqz nvzqz commented Sep 21, 2017

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.

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.
@rust-highfive
Copy link
Collaborator

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.

@shepmaster
Copy link
Member

Thanks for the awesome PR, @nvzqz! We'll wrangle up a top-notch reviewer for you in a short amount of time!

@shepmaster shepmaster added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Sep 22, 2017
@nvzqz nvzqz changed the title Implement TryFrom for array reference types Implement TryFrom<&[T]> for &[T; N] Sep 22, 2017
@jethrogb
Copy link
Contributor

I'd love to make arrays better, but shouldn't we wait for const generics?

@shepmaster
Copy link
Member

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.

@jethrogb
Copy link
Contributor

Is there a reason this would conflict

Not that I'm aware of. People have previously been cautious about metadata bloat though.

@nvzqz
Copy link
Contributor Author

nvzqz commented Sep 24, 2017

This change adds 66 new implementations of TryFrom, so I understand the concern about metadata bloat. However, I don't want to wait until integer generics to have this change. It seems likely that TryFrom will be stabilized way before that.

@BurntSushi
Copy link
Member

I haven't been following TryFrom or const generics, so I'd like to hand this off to someone else. @sfackler?

@BurntSushi BurntSushi assigned sfackler and unassigned BurntSushi Sep 25, 2017
@alexcrichton
Copy link
Member

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(());
Copy link
Member

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.

Copy link
Contributor Author

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?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See e45e8ab

@sfackler
Copy link
Member

I'm on board with these existing, but let's see if everyone is okay with more ad-hoc array stuff.

@rfcbot fcp merge

@sfackler sfackler added the T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. label Sep 28, 2017
@sfackler
Copy link
Member

Oops, forgot to libs tag it

@rfcbot fcp merge

@rfcbot
Copy link

rfcbot commented Sep 28, 2017

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.

@rfcbot rfcbot added the proposed-final-comment-period Proposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off. label Sep 28, 2017
@bluss
Copy link
Member

bluss commented Sep 29, 2017

slice.len() >= $N would still be valid, but I guess "slicing" to an array shorter than the input slice is not compatible with the spirit of the TryFrom trait (?).

@nvzqz
Copy link
Contributor Author

nvzqz commented Sep 29, 2017

I believe that the TryFrom conversions should be equal to the length of the slice. You can always do:

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();

@sfackler
Copy link
Member

In other similar situations like copy_from_slice and clone_from_slice, we require that the lengths match exactly.

@bors
Copy link
Contributor

bors commented Sep 30, 2017

☔ The latest upstream changes (presumably #44174) made this pull request unmergeable. Please resolve the merge conflicts.

@carols10cents
Copy link
Member

ping @BurntSushi and @aturon for your ticky boxes here!

@scottmcm
Copy link
Member

scottmcm commented Oct 9, 2017

If TryFrom starts allowing &[T] -> &]T; N], shouldn't From support &[T; N] -> &[T] for symmetry?

@SimonSapin
Copy link
Contributor

&[T; N] already coerce to &[T] implicitly in many places, so unless some specific code could use a From impl in a generic context, that impl doesn’t seem very useful. &[T] to &[T; N] on the other hand is new functionality that previously required unsafe code and macros to achieve.

@shepmaster shepmaster added S-waiting-on-team Status: Awaiting decision from the relevant subteam (see the T-<team> label). and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Oct 15, 2017
@shepmaster
Copy link
Member

ping @aturon for your ticky boxes here!

@nvzqz
Copy link
Contributor Author

nvzqz commented Oct 22, 2017

Is this just waiting on @aturon? It's been 3 weeks now 😕

@carols10cents
Copy link
Member

@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)
Copy link
Member

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?

Copy link
Contributor Author

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

Copy link
Contributor Author

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)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see, never mind.

@rfcbot rfcbot added the final-comment-period In the final comment period and will be merged soon unless new substantive objections are raised. label Oct 24, 2017
@rfcbot
Copy link

rfcbot commented Oct 24, 2017

🔔 This is now entering its final comment period, as per the review above. 🔔

@rfcbot rfcbot removed the proposed-final-comment-period Proposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off. label Oct 24, 2017
@alexcrichton
Copy link
Member

Egad sorry for the delay! This can now be approved after we've all signed off --

@bors: r+

@bors
Copy link
Contributor

bors commented Oct 31, 2017

📌 Commit 4c853ad has been approved by alexcrichton

@bors
Copy link
Contributor

bors commented Oct 31, 2017

⌛ Testing commit 4c853ad with merge f3b900c...

bors added a commit that referenced this pull request Oct 31, 2017
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.
@bors
Copy link
Contributor

bors commented Nov 1, 2017

☀️ Test successful - status-appveyor, status-travis
Approved by: alexcrichton
Pushing f3b900c to master...

@bors bors merged commit 4c853ad into rust-lang:master Nov 1, 2017
nvzqz added a commit to nvzqz/rust that referenced this pull request Jan 7, 2018
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.
@jethrogb
Copy link
Contributor

We're missing impl From<Infallible> for TryFromSliceError, see #60318

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
final-comment-period In the final comment period and will be merged soon unless new substantive objections are raised. S-waiting-on-team Status: Awaiting decision from the relevant subteam (see the T-<team> label). T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.