Change core::iter::Fuse's Default impl to do what its docs say it does by zachs18 · Pull Request #140985 · rust-lang/rust (original) (raw)

Conversation

This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.Learn more about bidirectional Unicode characters

[ Show hidden characters]({{ revealButtonHref }})

@zachs18

@rustbot rustbot added S-waiting-on-review

Status: Awaiting review from the assignee but also interested parties.

T-libs

Relevant to the library team, which will review and decide on the PR/issue.

labels

May 14, 2025

@zachs18 zachs18 changed the titleChange core::iter::Fuse's Default impl to do what it's docs say it does Change core::iter::Fuse's Default impl to do what its docs say it does

May 14, 2025

bors added a commit to rust-lang-ci/rust that referenced this pull request

May 15, 2025

@bors

Change core::iter::Fuse's Default impl to do what its docs say it does

The docs on impl<I: Default> Default for core::iter::Fuse<I> say (as the I: Default bound implies) that Fuse::<I>::default "Creates a Fuse iterator from the default value of I". However, the implementation creates a Fuse with Fuse { iter: Default::default() }, and since the iter field is an Option<I>, this is actually Fuse { iter: None }, not Fuse { iter: Some(I::default()) }, so Fuse::<I>::default() always returns an empty iterator, even if I::default() would not be empty.

This PR changes Fuse's Default implementation to match the documentation. This will be a behavior change for anyone currently using Fuse::<I>::default() where I::default() is not an empty iterator[^1], as Fuse::<I>::default() will now also not be an empty iterator.

(Alternately, the docs could be updated to reflect what the current implementation actually does, i.e. returns an always-exhausted iterator that never yields any items (even if I::default() would have yielded items). With this option, the I: Default bound could also be removed to reflect that no I is ever created.)

Current behavior example (maybe an example like this should be added to the docs either way?)

This PR changes publicly observable behavior, so I think requires at least a T-libs-api FCP?

r? libs-api

cc rust-lang#140961

impl<I: Default> Default for Fuse<I> was added in 1.70.0 (rust-lang#99929), and it's docs and behavior do not appear to have changed since (Fuse's iter field has been an Option since before the impl was added).

[^1]: IIUC it is a "de facto" guideline for the stdlib that an iterator type's default() should be empty (and for iterators where that would not make sense, they should not implement Default): cc rust-lang/libs-team#77 (comment) , so for stdlib iterators, I don't think this would change anything. However, if a user has a custom Iterator type I, and they are using Fuse<I>, and they call Fuse::<I>::default(), this may change the behavior of their code.

This was referenced

May 28, 2025

@rustbot rustbot added I-libs-api-nominated

Nominated for discussion during a libs-api team meeting.

T-libs-api

Relevant to the library API team, which will review and decide on the PR/issue.

and removed T-libs

Relevant to the library team, which will review and decide on the PR/issue.

labels

May 28, 2025

@rustbot rustbot added S-waiting-on-author

Status: This is awaiting some action (such as code changes or more information) from the author.

and removed S-waiting-on-review

Status: Awaiting review from the assignee but also interested parties.

labels

Jun 16, 2025

@zachs18

…oes.

Add a doctest with a non-empty-by-default iterator.

@rustbot rustbot added S-waiting-on-review

Status: Awaiting review from the assignee but also interested parties.

and removed S-waiting-on-author

Status: This is awaiting some action (such as code changes or more information) from the author.

labels

Jun 18, 2025

tgross35

@bors bors added S-waiting-on-bors

Status: Waiting on bors to run and complete tests. Bors will change the label on completion.

and removed S-waiting-on-review

Status: Awaiting review from the assignee but also interested parties.

labels

Jun 23, 2025

bors added a commit that referenced this pull request

Jun 24, 2025

@bors

Rollup of 9 pull requests

Successful merges:

r? @ghost @rustbot modify labels: rollup

rust-timer added a commit that referenced this pull request

Jun 24, 2025

@rust-timer

Rollup merge of #140985 - zachs18:fuse-default-some, r=tgross35

Change core::iter::Fuse's Default impl to do what its docs say it does

The docs on impl<I: Default> Default for core::iter::Fuse<I> say (as the I: Default bound implies) that Fuse::<I>::default "Creates a Fuse iterator from the default value of I". However, the implementation creates a Fuse with Fuse { iter: Default::default() }, and since the iter field is an Option<I>, this is actually Fuse { iter: None }, not Fuse { iter: Some(I::default()) }, so Fuse::<I>::default() always returns an empty iterator, even if I::default() would not be empty.

This PR changes Fuse's Default implementation to match the documentation. This will be a behavior change for anyone currently using Fuse::<I>::default() where I::default() is not an empty iterator[^1], as Fuse::<I>::default() will now also not be an empty iterator.

(Alternately, the docs could be updated to reflect what the current implementation actually does, i.e. returns an always-exhausted iterator that never yields any items (even if I::default() would have yielded items). With this option, the I: Default bound could also be removed to reflect that no I is ever created.)

Current behavior example (maybe an example like this should be added to the docs either way?)

This PR changes publicly observable behavior, so I think requires at least a T-libs-api FCP?

r? libs-api

cc #140961

impl<I: Default> Default for Fuse<I> was added in 1.70.0 (#99929), and it's docs and behavior do not appear to have changed since (Fuse's iter field has been an Option since before the impl was added).

[^1]: IIUC it is a "de facto" guideline for the stdlib that an iterator type's default() should be empty (and for iterators where that would not make sense, they should not implement Default): cc rust-lang/libs-team#77 (comment) , so for stdlib iterators, I don't think this would change anything. However, if a user has a custom Iterator type I, and they are using Fuse<I>, and they call Fuse::<I>::default(), this may change the behavior of their code.

tautschnig pushed a commit to model-checking/verify-rust-std that referenced this pull request

Jul 3, 2025

@workingjubilee

Change core::iter::Fuse's Default impl to do what its docs say it does

The docs on impl<I: Default> Default for core::iter::Fuse<I> say (as the I: Default bound implies) that Fuse::<I>::default "Creates a Fuse iterator from the default value of I". However, the implementation creates a Fuse with Fuse { iter: Default::default() }, and since the iter field is an Option<I>, this is actually Fuse { iter: None }, not Fuse { iter: Some(I::default()) }, so Fuse::<I>::default() always returns an empty iterator, even if I::default() would not be empty.

This PR changes Fuse's Default implementation to match the documentation. This will be a behavior change for anyone currently using Fuse::<I>::default() where I::default() is not an empty iterator[^1], as Fuse::<I>::default() will now also not be an empty iterator.

(Alternately, the docs could be updated to reflect what the current implementation actually does, i.e. returns an always-exhausted iterator that never yields any items (even if I::default() would have yielded items). With this option, the I: Default bound could also be removed to reflect that no I is ever created.)

Current behavior example (maybe an example like this should be added to the docs either way?)

This PR changes publicly observable behavior, so I think requires at least a T-libs-api FCP?

r? libs-api

cc rust-lang#140961

impl<I: Default> Default for Fuse<I> was added in 1.70.0 (rust-lang#99929), and it's docs and behavior do not appear to have changed since (Fuse's iter field has been an Option since before the impl was added).

[^1]: IIUC it is a "de facto" guideline for the stdlib that an iterator type's default() should be empty (and for iterators where that would not make sense, they should not implement Default): cc rust-lang/libs-team#77 (comment) , so for stdlib iterators, I don't think this would change anything. However, if a user has a custom Iterator type I, and they are using Fuse<I>, and they call Fuse::<I>::default(), this may change the behavior of their code.

wip-sync pushed a commit to NetBSD/pkgsrc-wip that referenced this pull request

Sep 20, 2025

@he32

Pkgsrc changes:

Upstream changes relative to 1.89.0:

Version 1.90 (2025-09-18)

Language

Compiler

Platform Support

Refer to Rust's platform support page for more information on Rust's tiered platform support.

Libraries

Stabilized APIs

These previously stable APIs are now stable in const contexts:

Cargo

Rustdoc

Compatibility Notes

tmeijn pushed a commit to tmeijn/dotfiles that referenced this pull request

Sep 24, 2025

@tmeijn

This MR contains the following updates:

Package Update Change
rust minor 1.89.0 -> 1.90.0

MR created with the help of el-capitano/tools/renovate-bot.

Proposed changes to behavior should be submitted there as MRs.

Release Notes

rust-lang/rust (rust)

v1.90.0

Compare Source

===========================

Language

Compiler

Platform Support

Refer to Rust's platform support page for more information on Rust's tiered platform support.

Libraries

Stabilized APIs

These previously stable APIs are now stable in const contexts:

Cargo

Rustdoc

Compatibility Notes

Configuration

📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever MR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this MR and you won't be reminded about this update again.

This MR has been generated by Renovate Bot.

netbsd-srcmastr pushed a commit to NetBSD/pkgsrc that referenced this pull request

Oct 18, 2025

@he32

Pkgsrc changes:

Upstream changes:

Version 1.90 (2025-09-18)

Language

Compiler

Platform Support

Refer to Rust's platform support page for more information on Rust's tiered platform support.

Libraries

Stabilized APIs

These previously stable APIs are now stable in const contexts:

Cargo

Rustdoc

Compatibility Notes

Version 1.89.0 (2025-08-07)

Language

Compiler

Platform Support

Refer to Rust's platform support page for more information on Rust's tiered platform support.

Libraries

Stabilized APIs

These previously stable APIs are now stable in const contexts:

Cargo

Rustdoc

Compatibility Notes

Internal Changes

These changes do not affect any public interfaces of Rust, but they represent significant improvements to the performance or internals of rustc and related tools.

netbsd-srcmastr pushed a commit to NetBSD/pkgsrc that referenced this pull request

Oct 23, 2025

@he32

Pkgsrc changes:

Upstream changes:

Version 1.90 (2025-09-18)

Language

Compiler

Platform Support

Refer to Rust's platform support page for more information on Rust's tiered platform support.

Libraries

Stabilized APIs

These previously stable APIs are now stable in const contexts:

Cargo

Rustdoc

Compatibility Notes

Version 1.89.0 (2025-08-07)

Language

Compiler

Platform Support

Refer to Rust's platform support page for more information on Rust's tiered platform support.

Libraries

Stabilized APIs

These previously stable APIs are now stable in const contexts:

Cargo

Rustdoc

Compatibility Notes

Internal Changes

These changes do not affect any public interfaces of Rust, but they represent significant improvements to the performance or internals of rustc and related tools.