new companion method to next_code_point() that accepts Iterator<Item=u8> #95788
Conversation
…but it accepts an iterator over u8 instead of &u8
|
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @dtolnay (or someone else) soon. Please see the contribution instructions for more information. |
rust-highfive
added
the
S-waiting-on-review
|
☔ The latest upstream changes (presumably #95798) made this pull request unmergeable. Please resolve the merge conflicts. |
|
☔ The latest upstream changes (presumably #95835) made this pull request unmergeable. Please resolve the merge conflicts. |
|
would resolve #95940 |
| @@ -34,8 +34,21 @@ pub(super) const fn utf8_is_cont_byte(byte: u8) -> bool { | |||
| #[unstable(feature = "str_internals", issue = "none")] | |||
| #[inline] | |||
| pub unsafe fn next_code_point<'a, I: Iterator<Item = &'a u8>>(bytes: &mut I) -> Option<u32> { | |||
| // SAFETY: `bytes` must produce a valid UTF-8-like (UTF-8 or WTF-8) string | |||
| unsafe { next_code_point_val(&mut bytes.copied()) } | |||
There was a problem hiding this comment.
considering that next_code_point is unstable, it's probably better to change next_code_point to take Iterator<Item = u8> directly. Any use can get fixed by using copied().
There was a problem hiding this comment.
I had considered that, but I wanted to minimize my impact, mostly because the process of running the unit tests takes a really long time. I can create a second branch that alters next_code_point to see if that version is preferred by folks with merge authority.
There was a problem hiding this comment.
#96019 is a variant that modifies next_code_point.
Since next_code_point() requires an Iterator<Item=&u8> and I only have an Iterator<Item=u8> I created next_code_point_val().
It is really just the same code, with the original method changed to invoke
next_code_point_val(&mut bytes.copied()). I threw in some unit tests because I want some confidence that I didn't break anything.