Skip to content

Debug impls of ExtractIf have inconsistent trait bounds #137654

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

Closed
dtolnay opened this issue Feb 26, 2025 · 5 comments · Fixed by #139764
Closed

Debug impls of ExtractIf have inconsistent trait bounds #137654

dtolnay opened this issue Feb 26, 2025 · 5 comments · Fixed by #139764
Labels
C-bug Category: This is a bug. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.

Comments

@dtolnay
Copy link
Member

dtolnay commented Feb 26, 2025

std::vec::ExtractIf has:

impl<T, F> Debug for ExtractIf<'_, T, F>
where
    T: Debug,
    F: Debug;

std::collections::linked_list::ExtractIf has:

impl<T, F> Debug for ExtractIf<'_, T, F>
where
    T: Debug;

std::collections::hash_set::ExtractIf has:

impl<T, F> Debug for ExtractIf<'_, T, F>
where
    F: FnMut(&T) -> bool;

std::collections::btree_set::ExtractIf has:

impl<T, F> Debug for ExtractIf<'_, T, F>
where
    T: Debug,
    F: FnMut(&T) -> bool;
Vec LinkedList HashSet BTreeSet
T: Debug ☑️ ☑️ ☑️
F: Debug ☑️
F: FnMut ☑️ ☑️

There should not need to be 4 different permutations for these 4 effectively-identical interfaces. We should be able to decide:

  • Should collection elements be printed or not.
  • Should the predicate be printed or not. Almost certainly not, given that closures do not implement Debug.
  • Should the Debug impl ever need to invoke the predicate. Almost certainly not.
@dtolnay dtolnay added C-bug Category: This is a bug. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. labels Feb 26, 2025
@rustbot rustbot added the needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. label Feb 26, 2025
@dtolnay
Copy link
Member Author

dtolnay commented Feb 26, 2025

This is time-sensitive for Rust 1.87 if we want to change any of the impls that were just stabilized in nightly.

@jieyouxu jieyouxu removed the needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. label Feb 26, 2025
@Noratrieb Noratrieb added the I-libs-api-nominated Nominated for discussion during a libs-api team meeting. label Feb 26, 2025
@m-ou-se
Copy link
Member

m-ou-se commented Mar 18, 2025

The ExtractIf types for Vec, LinkedList and HashSet have been stabilized in 1.87, which is still in nightly.

The one for BTreeSet is still unstable.

@m-ou-se
Copy link
Member

m-ou-se commented Mar 18, 2025

There should not need to be 4 different permutations for these 4 effectively-identical interfaces. We should be able to decide:

* Should collection elements be printed or not.

* Should the predicate be printed or not. Almost certainly not, given that closures do not implement Debug.

* Should the Debug impl ever need to invoke the predicate. Almost certainly not.

It sounds to me like it should in all cases be T: Debug only, like the one of LinkedList.

@BurntSushi
Copy link
Member

I agree. Just T: Debug only seems like the right call here. Nice catch @dtolnay!

@dtolnay
Copy link
Member Author

dtolnay commented Apr 13, 2025

@Amanieu Amanieu removed the I-libs-api-nominated Nominated for discussion during a libs-api team meeting. label Apr 15, 2025
GuillaumeGomez added a commit to GuillaumeGomez/rust that referenced this issue May 5, 2025
Consistent trait bounds for ExtractIf Debug impls

Closes rust-lang#137654. Refer to that issue for a table of the **4** different impl signatures we previously had in the standard library for Debug impls of various ExtractIf iterator types.

The one we are standardizing on is the one so far only used by `alloc::collections::linked_list::ExtractIf`, which is _no_ `F: Debug` bound, _no_ `F: FnMut` bound, only `T: Debug` bound.

This PR applies the following signature changes:

```diff
/* alloc::collections::btree_map */

    pub struct ExtractIf<'a, K, V, F, A = Global>
    where
-       F: 'a + FnMut(&K, &mut V) -> bool,
        Allocator + Clone,

    impl Debug for ExtractIf<'a, K, V, F,
+       A,
    >
    where
        K: Debug,
        V: Debug,
-       F: FnMut(&K, &mut V) -> bool,
+       A: Allocator + Clone,
```

```diff
/* alloc::collections::btree_set */

    pub struct ExtractIf<'a, T, F, A = Global>
    where
-       T: 'a,
-       F: 'a + FnMut(&T) -> bool,
        Allocator + Clone,

    impl Debug for ExtractIf<'a, T, F, A>
    where
        T: Debug,
-       F: FnMut(&T) -> bool,
        A: Allocator + Clone,
```

```diff
/* alloc::collections::linked_list */

    impl Debug for ExtractIf<'a, T, F,
+       A,
    >
    where
        T: Debug,
+       A: Allocator,
```

```diff
/* alloc::vec */

    impl Debug for ExtractIf<'a, T, F, A>
    where
        T: Debug,
-       F: Debug,
        A: Allocator,
-       A: Debug,
```

```diff
/* std::collections::hash_map */

    pub struct ExtractIf<'a, K, V, F>
    where
-       F: FnMut(&K, &mut V) -> bool,

    impl Debug for ExtractIf<'a, K, V, F>
    where
+       K: Debug,
+       V: Debug,
-       F: FnMut(&K, &mut V) -> bool,
```

```diff
/* std::collections::hash_set */

    pub struct ExtractIf<'a, T, F>
    where
-       F: FnMut(&T) -> bool,

    impl Debug for ExtractIf<'a, T, F>
    where
+       T: Debug,
-       F: FnMut(&T) -> bool,
```

I have made the following changes to bring these types into better alignment with one another.

- Delete `F: Debug` bounds. These are especially problematic because Rust closures do not come with a Debug impl, rendering the impl useless.

- Delete `A: Debug` bounds. Allocator parameters are unstable for now, but in the future this would become an API commitment that we do not debug-print a representation of the allocator when printing an iterator.

- Delete `F: FnMut` bounds. Requires `hashbrown` PR: rust-lang/hashbrown#616. **API commitment:** we commit to not doing RefCell voodoo inside ExtractIf to have some way for its Debug impl (which takes &amp;self) to call a FnMut closure, if this is even possible.

- Add `T: Debug` bounds (or `K`/`V`), even on Debug impls that do not currently make use of them, but might in the future. **Breaking change.** Must backport into Rust 1.87 (current beta) or do a de-stabilization PR in beta to delay those types by one release.

- Render using `debug_struct` + `finish_non_exhaustive`, instead of `debug_tuple`.

- Do not render the _entire_ underlying collection.

- Show a "peek" field indicating the current position of the iterator.
@bors bors closed this as completed in 5ca0053 May 6, 2025
rust-timer added a commit to rust-lang-ci/rust that referenced this issue May 6, 2025
Rollup merge of rust-lang#139764 - dtolnay:extractif, r=Amanieu

Consistent trait bounds for ExtractIf Debug impls

Closes rust-lang#137654. Refer to that issue for a table of the **4** different impl signatures we previously had in the standard library for Debug impls of various ExtractIf iterator types.

The one we are standardizing on is the one so far only used by `alloc::collections::linked_list::ExtractIf`, which is _no_ `F: Debug` bound, _no_ `F: FnMut` bound, only `T: Debug` bound.

This PR applies the following signature changes:

```diff
/* alloc::collections::btree_map */

    pub struct ExtractIf<'a, K, V, F, A = Global>
    where
-       F: 'a + FnMut(&K, &mut V) -> bool,
        Allocator + Clone,

    impl Debug for ExtractIf<'a, K, V, F,
+       A,
    >
    where
        K: Debug,
        V: Debug,
-       F: FnMut(&K, &mut V) -> bool,
+       A: Allocator + Clone,
```

```diff
/* alloc::collections::btree_set */

    pub struct ExtractIf<'a, T, F, A = Global>
    where
-       T: 'a,
-       F: 'a + FnMut(&T) -> bool,
        Allocator + Clone,

    impl Debug for ExtractIf<'a, T, F, A>
    where
        T: Debug,
-       F: FnMut(&T) -> bool,
        A: Allocator + Clone,
```

```diff
/* alloc::collections::linked_list */

    impl Debug for ExtractIf<'a, T, F,
+       A,
    >
    where
        T: Debug,
+       A: Allocator,
```

```diff
/* alloc::vec */

    impl Debug for ExtractIf<'a, T, F, A>
    where
        T: Debug,
-       F: Debug,
        A: Allocator,
-       A: Debug,
```

```diff
/* std::collections::hash_map */

    pub struct ExtractIf<'a, K, V, F>
    where
-       F: FnMut(&K, &mut V) -> bool,

    impl Debug for ExtractIf<'a, K, V, F>
    where
+       K: Debug,
+       V: Debug,
-       F: FnMut(&K, &mut V) -> bool,
```

```diff
/* std::collections::hash_set */

    pub struct ExtractIf<'a, T, F>
    where
-       F: FnMut(&T) -> bool,

    impl Debug for ExtractIf<'a, T, F>
    where
+       T: Debug,
-       F: FnMut(&T) -> bool,
```

I have made the following changes to bring these types into better alignment with one another.

- Delete `F: Debug` bounds. These are especially problematic because Rust closures do not come with a Debug impl, rendering the impl useless.

- Delete `A: Debug` bounds. Allocator parameters are unstable for now, but in the future this would become an API commitment that we do not debug-print a representation of the allocator when printing an iterator.

- Delete `F: FnMut` bounds. Requires `hashbrown` PR: rust-lang/hashbrown#616. **API commitment:** we commit to not doing RefCell voodoo inside ExtractIf to have some way for its Debug impl (which takes &amp;self) to call a FnMut closure, if this is even possible.

- Add `T: Debug` bounds (or `K`/`V`), even on Debug impls that do not currently make use of them, but might in the future. **Breaking change.** Must backport into Rust 1.87 (current beta) or do a de-stabilization PR in beta to delay those types by one release.

- Render using `debug_struct` + `finish_non_exhaustive`, instead of `debug_tuple`.

- Do not render the _entire_ underlying collection.

- Show a "peek" field indicating the current position of the iterator.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-bug Category: This is a bug. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants