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

Tracking issue for str_checked_slicing #39932

Closed
nagisa opened this issue Feb 18, 2017 · 11 comments
Closed

Tracking issue for str_checked_slicing #39932

nagisa opened this issue Feb 18, 2017 · 11 comments
Labels
B-unstable Blocker: Implemented in the nightly compiler and unstable. C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. final-comment-period In the final comment period and will be merged soon unless new substantive objections are raised. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.

Comments

@nagisa
Copy link
Member

nagisa commented Feb 18, 2017

slice::get_unchecked now takes ranges, whereas str takes explicit usize. str does not provide an explicit method to slice unsafely with ranges either.

@alexcrichton
Copy link
Member

Should be a relatively easy API to add! I believe this just needs to mirror slices and can likely use the same trait for abstractions.

@alexcrichton alexcrichton added the E-help-wanted Call for participation: Help is requested to fix this issue. label Feb 21, 2017
@ghost
Copy link

ghost commented Feb 21, 2017

i'd like to do it

@steveklabnik steveklabnik added T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. and removed A-libs labels Mar 24, 2017
bors added a commit that referenced this issue Mar 31, 2017
@Mark-Simulacrum Mark-Simulacrum added B-unstable Blocker: Implemented in the nightly compiler and unstable. and removed E-help-wanted Call for participation: Help is requested to fix this issue. labels Jun 19, 2017
@Mark-Simulacrum Mark-Simulacrum changed the title API discrepancy between slice::get{,_unchecked} and str::slice_unchecked Tracking issue for str_checked_slicing Jun 19, 2017
@Mark-Simulacrum
Copy link
Member

Nominating for libs team discussion -- I think it's reasonable to stabilize this. It's been implemented for about two cycles (PR merged March 31st), I believe. The API surface is fairly small -- extending slice get{,_unchecked} methods to strs. It's possible we should deprecate the slice_unchecked{,_mut} methods as we stabilize this extension -- I believe they are obsoleted by this addition.

@alexcrichton
Copy link
Member

@rfcbot fcp merge

Sounds good to me to stabilize!

@alexcrichton
Copy link
Member

Note though that we should avoid deprecating stable functions until the alternative, get_unchecked, has hit stable.

@Mark-Simulacrum
Copy link
Member

Wouldn't deprecating and stabilizing at the same time work? Then all code can transition immediately, right?

@rfcbot
Copy link

rfcbot commented Jun 20, 2017

Team member @alexcrichton 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.

@alexcrichton
Copy link
Member

@Mark-Simulacrum nah unfortunately the downside of that is that if you have a library which spans all three channels it's impossible to compile without warnings. On stable you can't use the replacement and on nightly you get warnings. The alternative is that we wait for all three channels to have the replacement, then we turn the warnings on, and that way libraries which span all three channels can immediately update to the newer methods and take action to rid the warnings.

@brson
Copy link
Contributor

brson commented Jul 13, 2017

Yeah it's best to wait to deprecate things until their replacements are stable a while. As soon as you publish a deprecation to nightly people will start migrating away from it and breaking their own downstreams, and breaking backwards compatibility. Best to leave a stable compatibility window.

@rfcbot
Copy link

rfcbot commented Jul 13, 2017

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

@rfcbot rfcbot added the final-comment-period In the final comment period and will be merged soon unless new substantive objections are raised. label Jul 13, 2017
@Mark-Simulacrum Mark-Simulacrum added the C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. label Jul 22, 2017
@rfcbot
Copy link

rfcbot commented Jul 23, 2017

The final comment period is now complete.

@bors bors closed this as completed in 46de2af Jul 27, 2017
alexcrichton added a commit to alexcrichton/rust that referenced this issue Aug 12, 2017
Stabilized

* `<str>::get`
* `<str>::get_mut`
* `<str>::get_unchecked`
* `<str>::get_unchecked_mut`

Closes rust-lang#39932
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
B-unstable Blocker: Implemented in the nightly compiler and unstable. C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. final-comment-period In the final comment period and will be merged soon unless new substantive objections are raised. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

7 participants