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.

Sign up for GitHub

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

Jump to bottom

Should std::str::CharRange be public? #9387

Closed
Kimundi opened this issue Sep 21, 2013 · 5 comments
Closed

Should std::str::CharRange be public? #9387

Kimundi opened this issue Sep 21, 2013 · 5 comments
Labels
I-needs-decision Issue: In need of a decision. P-medium Medium priority

Comments

@Kimundi
Copy link
Member

Kimundi commented Sep 21, 2013

Currenty, str exports both CharRange and methods for getting an CharRange at an specific byte index of the string.

However, with Iterators we might not really need those to be public, and if we get an encoding module they might have to migrate to there anyway, as they are specific to the utf8 representation of a string.
@bluss
Copy link
Member

bluss commented Sep 21, 2013

Encoding support doesn't change that str is using UTF-8 for its internal representation, and that this is also exposed in some parts of its interface, including when slicing (using byte indices). I think .char_range_at has a role for manual traversal through the string, even though it's not supposed to be used often.

@aturon aturon added the A-libs label Jun 3, 2014
@aturon
Copy link
Member

aturon commented Feb 16, 2015

Nominating for 1.0-beta P-backcompat-libs: we need to finalize the story around these methods.

@steveklabnik steveklabnik added P-backcompat-libs I-needs-decision Issue: In need of a decision. and removed I-nominated labels Feb 19, 2015
@steveklabnik steveklabnik added this to the 1.0 beta milestone Feb 19, 2015
@pnkfelix
Copy link
Member

1.0 beta, P-backcompat-libs, I-needs-decision.

alexcrichton added a commit to alexcrichton/rust that referenced this issue Mar 11, 2015
@alexcrichton
std: Deprecate the str::CharRange type
c24ef07 
This struct and the associated functions `char_range_at` and
`char_range_at_reverse` have been unstable for some time now, and it looks like
with a combination of `char_at` plus `char_at_reverse` plus `len_utf8` that the
structure isn't necessary at this time.

The structure and perhaps more fanciful unicode processing support could be
added at a later date, but for now the types are being deprecated and slated for
removal.

Any code currently using `CharRange` can instead use the `char_at` and
`char_at_reverse` methods plus the `len_utf8` method on `char` as a replacement.

Closes rust-lang#9387
[breaking-change]
This was referenced Mar 11, 2015
Closed
Merged
@alexcrichton
Copy link
Member

This is now explicitly behind its own feature gate so I'm going to de-milestone this issue as we will probably not stabilize it for 1.0 at this rate.

@alexcrichton alexcrichton removed this from the 1.0 beta milestone Mar 19, 2015
@brson brson added P-medium Medium priority and removed P-backcompat-libs labels Apr 24, 2015
@huonw
Copy link
Member

huonw commented Jan 5, 2016

Closing in favour of the tracking issue for the feature gate: #27754.

@huonw huonw closed this as completed Jan 5, 2016
@huonw huonw mentioned this issue Jan 5, 2016
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
I-needs-decision Issue: In need of a decision. P-medium Medium priority
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

std: Deprecate the str::CharRange type alexcrichton/rust
8 participants
@steveklabnik @alexcrichton @brson @pnkfelix @aturon @huonw @Kimundi @bluss