core::str::{chars_uppercase,chars_lowercase} iterators

[markokr]

They are based on new UnicodeConverter + UnicodeIterator
internal API that supports context-sensitivity and char expansion.

API change proposal: rust-lang/libs-team#58

[rust-highfive]

Hey! It looks like you've submitted a new PR for the library teams!

If this PR contains changes to any rust-lang/rust public library APIs then please comment with @rustbot label +T-libs-api -T-libs to tag it appropriately. If this PR contains changes to any unstable APIs please edit the PR description to add a link to the relevant API Change Proposal or create one if you haven't already. If you're unsure where your change falls no worries, just leave it as is and the reviewer will take a look and make a decision to forward on if necessary.

Examples of T-libs-api changes:

• Stabilizing library features
• Introducing insta-stable changes such as new implementations of existing stable traits on existing stable types
• Introducing new or changing existing unstable library APIs (excluding permanently unstable features / features without a tracking issue)
• Changing public documentation in ways that create new stability guarantees
• Changing observable runtime behavior of library APIs

[rust-highfive]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @thomcc (or someone else) soon.

Please see the contribution instructions for more information.

[thomcc]

This is a new API, so please file an API change proposal (see the links in the bot post). That said, I'm very much in favor of this, and a quick skim (will need more thorough review once it gets API sign off) looks fine.

@rustbot label +T-libs-api -T-libs

[markokr]

Thanks for quick feedback!

Created API proposal here: rust-lang/libs-team#58

[thomcc]

Hmm, the implementation here is more generic than it needs to be, and more complex as a result. You should not do this via a trait IMO -- The way you've decoupled it here also requires more bounds-checks which shouldn't be needed, and avoiding them in this interface would require otherwise-unnecessary unsafe code (to be clear: I'm not asking for you to add unsafe to this).

I think chars_lowercase should be a bit more like what you'd get by manually performing s.chars().flat_map(|c| c.to_lowercase()). Uppercase is the complex one, but should be handled directly, closer to the implementation in liballoc.

Let me know if you need an example of what I mean.

[thomcc]

I think this shouldn't use a trait. I think this ends up complicating things quite a bit and makes the implementation overly generic.

[thomcc]

nit: forward/backward instead of fwd/bwd.

[thomcc]

This feature name is too generic, perhaps something more like #![feature(str_chars_casemapped)]?

[bors]

☔ The latest upstream changes (presumably #100644) made this pull request unmergeable. Please resolve the merge conflicts.

[JohnCSimon]

Ping from triage:
@markokr what is the status of this PR?

[JohnCSimon]

@markokr
Ping from triage: I'm closing this due to inactivity, Please reopen when you are ready to continue with this.
Note: if you do please open the PR BEFORE you push to it, else you won't be able to reopen - this is a quirk of github.
Thanks for your contribution.

@rustbot label: +S-inactive