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

Stabilize the core::array module and reexport in std (for TryFromSliceError) #60014

Closed
ollie27 opened this issue Apr 16, 2019 · 7 comments
Closed
Labels
beta-accepted Accepted for backporting to the compiler in the beta channel. C-bug Category: This is a bug. disposition-merge This issue / PR is in PFCP or FCP with a disposition to merge it. finished-final-comment-period The final comment period is finished for this PR / Issue. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.

Comments

@ollie27
Copy link
Member

ollie27 commented Apr 16, 2019

TryFromSliceError has been stabilized in core::array but core::array is an unstable module. Additionally TryFromSliceError isn't re-exported anywhere in std. There isn't even a std::array module to re-export it into.

cc @rust-lang/libs

@jonas-schievink jonas-schievink added C-bug Category: This is a bug. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. T-release Relevant to the release subteam, which will review and decide on the PR/issue. labels Apr 16, 2019
@jonas-schievink
Copy link
Contributor

cc @rust-lang/release another missed libstd reexport

@Mark-Simulacrum Mark-Simulacrum added stable-accepted Accepted for backporting to the compiler in the stable channel. stable-nominated Nominated for backporting to the compiler in the stable channel. and removed stable-accepted Accepted for backporting to the compiler in the stable channel. labels Apr 16, 2019
@Centril
Copy link
Contributor

Centril commented Apr 16, 2019

Can @rust-lang/libs confirm that you wish to stabilize TryFromSliceError in core::array?

@alexcrichton
Copy link
Member

I suspect that we want this type stable but probably not in core::array but rather in {core,std,alloc}::slice.

@SimonSapin SimonSapin added beta-accepted Accepted for backporting to the compiler in the beta channel. and removed T-release Relevant to the release subteam, which will review and decide on the PR/issue. stable-nominated Nominated for backporting to the compiler in the stable channel. labels Apr 17, 2019
@SimonSapin SimonSapin changed the title TryFromSliceError is only available in core::array which is unstable Stabilize the core::array module and reexport in std (for TryFromSliceError) Apr 17, 2019
@SimonSapin
Copy link
Contributor

SimonSapin commented Apr 17, 2019

The libs team discussed this in today’s triage meeting. std::slice was suggested as an alternative location for this type, but David pointed out that array::TryFromSliceError reads better than slice::TryFromSliceError. Additionally, we expect to have more array-related APIs (e.g. iterator types) in the future. So consensus was to stabilize the array module and reexport it in std.

We feel comfortable backporting this to beta, but backporting to stable and mentioning this in a point release blog post seems excessive. This error type is part of another of a return type in another API and typically does not need to be named.

Since std::array hasn’t been formally proposed before, let’s do the process dance:

@rfcbot fcp merge

@rfcbot
Copy link

rfcbot commented Apr 17, 2019

Team member @SimonSapin 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 rfcbot added proposed-final-comment-period Proposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off. disposition-merge This issue / PR is in PFCP or FCP with a disposition to merge it. labels Apr 17, 2019
@rfcbot rfcbot added the final-comment-period In the final comment period and will be merged soon unless new substantive objections are raised. label Apr 29, 2019
@rfcbot
Copy link

rfcbot commented Apr 29, 2019

🔔 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 Apr 29, 2019
@rfcbot rfcbot added the finished-final-comment-period The final comment period is finished for this PR / Issue. label May 9, 2019
@rfcbot
Copy link

rfcbot commented May 9, 2019

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.

The RFC will be merged soon.

@rfcbot rfcbot removed the final-comment-period In the final comment period and will be merged soon unless new substantive objections are raised. label May 9, 2019
@bors bors closed this as completed in e40f9a6 May 9, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
beta-accepted Accepted for backporting to the compiler in the beta channel. C-bug Category: This is a bug. disposition-merge This issue / PR is in PFCP or FCP with a disposition to merge it. finished-final-comment-period The final comment period is finished for this PR / Issue. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants