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

Comments

Projects
None yet
7 participants
@ollie27
Copy link
Contributor

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

This comment has been minimized.

Copy link
Member

commented Apr 16, 2019

cc @rust-lang/release another missed libstd reexport

@Centril

This comment has been minimized.

Copy link
Contributor

commented Apr 16, 2019

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

@alexcrichton

This comment has been minimized.

Copy link
Member

commented Apr 17, 2019

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

@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

This comment has been minimized.

Copy link
Contributor

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

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link

commented Apr 29, 2019

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

@rfcbot

This comment has been minimized.

Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.