add default FromIterator for types with Default and Extend trait

[HernandoR]

relating to #58659
r? @hkBst

[rustbot]

Failed to set assignee to hkBst: invalid assignee

Note: Only org members with at least the repository "read" role, users with write permissions, or people who have commented on the PR may be assigned.

[HernandoR]

Sorry, bad source branch. The labels may be incorrect, shall I start a new pr?

[hkBst]

Unfortunately unstable impl's are not supported (yet?), so you should remove this line and its accompanying feature.

[hkBst]

Should be #[stable(feature = "from_iter_default", since = "CURRENT_RUSTC_VERSION")], and I was probably wrong about removing the feature.

[rustbot]

Failed to set assignee to hkBst: invalid assignee

Note: Only org members with at least the repository "read" role, users with write permissions, or people who have commented on the PR may be assigned.

[HernandoR]

Suppose there is a tuple type (Vec<i32>, Vec<&str>) that satisfies both:

The constraints of the generic implementation: (Vec<i32>, Vec<&str>): Default + Extend<(i32, &str)> (since each element Vec implements Default and Extend).
The constraints of the tuple implementation: Vec<i32>: Default + Extend<i32> and Vec<&str>: Default + Extend<&str>.

In this case, when from_iter is called, the compiler would need to choose between:

The generic implementation: with T = (Vec<i32>, Vec<&str>) and A = (i32, &str).
The tuple implementation: the specialized implementation generated specifically for this tuple.

In theory, the tuple implementation is more specific. However, the compiler cannot confirm the safety of this specialization—because both implementations rely on the core logic of Default::default() and Extend::extend, whose behavior is defined by external traits (Default/Extend). The compiler cannot guarantee that their behavior in the tuple scenario will be consistent with the generic scenario.

[HernandoR]

i could not tell if feature = "specialization" is enabled in my local test, how to make ./x build and test for a nightly version of rust lib? i.e. with specialization feature enabled

[rust-log-analyzer]

The job pr-check-1 failed! Check out the build log: (web) (plain enhanced) (plain)

Click to see the possible cause of the failure (guessed by this bot)

[RUSTC-TIMING] build_script_build test:false 0.334
    Checking la-arena v0.3.1
[RUSTC-TIMING] la_arena test:false 0.328
   Compiling zerovec-derive v0.11.1
error[E0277]: a value of type `(Vec<N>, Vec<rowan::SyntaxNode<RustLanguage>>)` cannot be built from an iterator over elements of type `(N, rowan::SyntaxNode<RustLanguage>)`
    --> src/tools/rust-analyzer/crates/syntax/src/ast/syntax_factory/constructors.rs:1332:10
     |
1332 |         .collect()
     |          ^^^^^^^ value of type `(Vec<N>, Vec<rowan::SyntaxNode<RustLanguage>>)` cannot be built from `std::iter::Iterator<Item=(N, rowan::SyntaxNode<RustLanguage>)>`
     |
     = help: the trait `FromIterator<(N, rowan::SyntaxNode<RustLanguage>)>` is not implemented for `(Vec<N>, Vec<rowan::SyntaxNode<RustLanguage>>)`
     = help: the trait `FromIterator<()>` is implemented for `()`
note: the method call chain might not have had the expected associated types
    --> src/tools/rust-analyzer/crates/syntax/src/ast/syntax_factory/constructors.rs:1328:10
     |
1326 |       input
     |       ----- this expression has type `impl IntoIterator<Item = N>`
1327 |           .into_iter()
     |            ----------- `Iterator::Item` is `N` here
1328 |           .map(|it| {
     |  __________^
1329 | |             let syntax = it.syntax().clone();
1330 | |             (it, syntax)
1331 | |         })
     | |__________^ `Iterator::Item` changed to `(N, SyntaxNode<RustLanguage>)` here
note: required by a bound in `collect`
    --> /checkout/library/core/src/iter/traits/iterator.rs:2014:19
     |
2014 |     fn collect<B: FromIterator<Self::Item>>(self) -> B
     |                   ^^^^^^^^^^^^^^^^^^^^^^^^ required by this bound in `Iterator::collect`

[RUSTC-TIMING] zerovec_derive test:false 2.712
   Compiling displaydoc v0.2.5
[RUSTC-TIMING] displaydoc test:false 1.236
   Compiling query-group-macro v0.0.0 (/checkout/src/tools/rust-analyzer/crates/query-group-macro)

[hkBst]

@HernandoR I'm not sure what's going wrong here. Combining these impl seems to work fine on the playground: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2024&gist=1f1f887ddb3205ed2a3d488d7f05955f.

I'm reading up on specialization, but it's probably a good idea to ask for help on Zulip.

[QuineDot]

As a blanket implementation, this would be a major breaking change.

I can have this today, and this change conflicts with it.

#[derive(Default)]
struct S(usize);

impl<I> Extend<I> for S {
    fn extend<T: IntoIterator<Item = I>>(&mut self, iter: T) {
        self.0 += iter.into_iter().count();
    }
}

impl<I> FromIterator<I> for S {
    fn from_iter<T: IntoIterator<Item = I>>(iter: T) -> Self {
        Self(
            iter.into_iter().count() + 100
        )
    }
}

[HernandoR]

@QuineDot I think that's exactly what feature specialization trying to solve: Providing a default implement for a trait that would be overridden if any more "specific" implement is provided