-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
Make EncodeWide implement FusedIterator #96397
Conversation
Hey! It looks like you've submitted a new PR for the library teams! If this PR contains changes to any Examples of
|
(rust-highfive has picked a reviewer for you, use r? to override) |
r? rust-lang/libs-api @rustbot label +T-libs-api -T-libs |
As @scottmcm said, this is instantly stable so it does need to be signed off by the libs-api team. But I don't anticipate there being any concerns for reasons noted in the OP. |
@rust-lang/libs-api: |
Team member @dtolnay has proposed to merge this. The next step is review by the rest of the tagged team members: No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See this document for info about what commands tagged team members can give me. |
🔔 This is now entering its final comment period, as per the review above. 🔔 |
@bors r+ |
📌 Commit fc6af81 has been approved by |
Make EncodeWide implement FusedIterator [`EncodeUtf16`](https://doc.rust-lang.org/std/str/struct.EncodeUtf16.html) and [`EncodeWide`](https://doc.rust-lang.org/std/os/windows/ffi/struct.EncodeWide.html) currently serve similar purposes: They convert from UTF-8 to UTF-16 and WTF-8 to WTF-16, respectively. `EncodeUtf16` wraps a &str, whereas `EncodeWide` wraps an &OsStr. When Iteration has concluded, these iterators wrap an empty slice, which will forever yield `None` values. Hence, `EncodeUtf16` rightfully implements `FusedIterator`. However, `EncodeWide` in contrast does not, even though it serves an almost identical purpose. This PR attempts to fix that issue. I consider this change minor and non-controversial, hence why I have not added a RFC/FCP. Please let me know if the stability attribute is wrong or contains a wrong version number. Thanks in advance. Fixes rust-lang#96368
Make EncodeWide implement FusedIterator [`EncodeUtf16`](https://doc.rust-lang.org/std/str/struct.EncodeUtf16.html) and [`EncodeWide`](https://doc.rust-lang.org/std/os/windows/ffi/struct.EncodeWide.html) currently serve similar purposes: They convert from UTF-8 to UTF-16 and WTF-8 to WTF-16, respectively. `EncodeUtf16` wraps a &str, whereas `EncodeWide` wraps an &OsStr. When Iteration has concluded, these iterators wrap an empty slice, which will forever yield `None` values. Hence, `EncodeUtf16` rightfully implements `FusedIterator`. However, `EncodeWide` in contrast does not, even though it serves an almost identical purpose. This PR attempts to fix that issue. I consider this change minor and non-controversial, hence why I have not added a RFC/FCP. Please let me know if the stability attribute is wrong or contains a wrong version number. Thanks in advance. Fixes rust-lang#96368
Make EncodeWide implement FusedIterator [`EncodeUtf16`](https://doc.rust-lang.org/std/str/struct.EncodeUtf16.html) and [`EncodeWide`](https://doc.rust-lang.org/std/os/windows/ffi/struct.EncodeWide.html) currently serve similar purposes: They convert from UTF-8 to UTF-16 and WTF-8 to WTF-16, respectively. `EncodeUtf16` wraps a &str, whereas `EncodeWide` wraps an &OsStr. When Iteration has concluded, these iterators wrap an empty slice, which will forever yield `None` values. Hence, `EncodeUtf16` rightfully implements `FusedIterator`. However, `EncodeWide` in contrast does not, even though it serves an almost identical purpose. This PR attempts to fix that issue. I consider this change minor and non-controversial, hence why I have not added a RFC/FCP. Please let me know if the stability attribute is wrong or contains a wrong version number. Thanks in advance. Fixes rust-lang#96368
Rollup of 7 pull requests Successful merges: - rust-lang#96377 (make `fn() -> _ { .. }` suggestion MachineApplicable) - rust-lang#96397 (Make EncodeWide implement FusedIterator) - rust-lang#96421 (Less `NoDelim`) - rust-lang#96432 (not need `Option` for `dbg_scope`) - rust-lang#96466 (Better error messages when collecting into `[T; n]`) - rust-lang#96471 (replace let else with `?`) - rust-lang#96483 (Add missing `target_feature` to the list of well known cfg names) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
…or, r=dtolnay Implement FusedIterator for DecodeUtf16 when the inner iterator does I have just implemented an iterator that wraps `DecodeUtf16` and wanted to implement `FusedIterator` for my iterator when I noticed that `DecodeUtf16` currently doesn't implement `FusedIterator` at all. A quick look at the code of `DecodeUtf16` revealed that `DecodeUtf16::next` only returns `None` when its inner iterator returns `None`: https://github.com/rust-lang/rust/blob/3462f79e94f466a56ddaccfcdd3a3d44dd1dda9f/library/core/src/char/decode.rs#L45 As a result, we can implement `FusedIterator` for `DecodeUtf16` when the inner iterator does. I'm following the example of rust-lang#96397 here and consider this change minor and non-controversial, which is why I haven't added an RFC. I have also added the required feature name (`"decode_utf16_fused_iterator"`), however without adding a chapter to the Rust Unstable book (same as rust-lang#96397).
EncodeUtf16
andEncodeWide
currently serve similar purposes: They convert from UTF-8 to UTF-16 and WTF-8 to WTF-16, respectively.EncodeUtf16
wraps a &str, whereasEncodeWide
wraps an &OsStr.When Iteration has concluded, these iterators wrap an empty slice, which will forever yield
None
values. Hence,EncodeUtf16
rightfully implementsFusedIterator
. However,EncodeWide
in contrast does not, even though it serves an almost identical purpose.This PR attempts to fix that issue. I consider this change minor and non-controversial, hence why I have not added a RFC/FCP. Please let me know if the stability attribute is wrong or contains a wrong version number. Thanks in advance.
Fixes #96368