new companion method to next_code_point() that accepts Iterator<Item=u8>#95788
new companion method to next_code_point() that accepts Iterator<Item=u8>#95788mutantbob wants to merge 6 commits intorust-lang:masterfrom
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. |
|
☔ 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 |
| #[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.
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.