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

std: Deprecate the str::CharRange type #23268

Closed

Conversation

alexcrichton
Copy link
Member

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 #9387
[breaking-change]

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

r? @nikomatsakis

(rust_highfive has picked a reviewer for you, use r? to override)

@aturon aturon mentioned this pull request Mar 11, 2015
91 tasks
@alexcrichton
Copy link
Member Author

r? @aturon (but feel free to reassign as I keep piling things on you...)

@rust-highfive rust-highfive assigned aturon and unassigned nikomatsakis Mar 11, 2015
@aturon
Copy link
Member

aturon commented Mar 12, 2015

I'm curious about the rationale for this decision instead of, for example, deprecating char_at in favor of char_range_at. The latter is a bit less convenient when all you want is the character, but it avoids recomputing the length when you need that.

@alexcrichton
Copy link
Member Author

Honestly I didn't really give it too much consideration, I figured we were going to stabilize char_at and CharRange offered more API surface area to stabilize so I just wanted to minimized what we had to stabilize :).

I'd have to do some benchmarking to see if recomputing the length actually matters that much, I suspect that "performance critical" use cases should be using chars or char_indices though. The actual implementation of len_utf8, however, is quite small and may not actually be a performance concern (hence the need for a benchmark)

@aturon
Copy link
Member

aturon commented Mar 12, 2015

OK, if you see char_at as a necessary API regardless then this seems fine.

FWIW, though, I don't think we need to deprecate all unstable APIs that we don't plan to ship in 1.0. It's fine for some stuff to sit as unstable, and garner support from the nightly crowd in terms of eventual stabilization.

@alexcrichton
Copy link
Member Author

Yeah that's a good point, I also wouldn't mind just leaving this as #[unstable] here for awhile longer.

@alexcrichton
Copy link
Member Author

Closing in favor of #23461

@alexcrichton alexcrichton deleted the deprecate-char-range branch March 17, 2015 23:29
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Should std::str::CharRange be public?
4 participants