Function that returns impl Iterator<Item = Box<dyn Iterator<Item = i32>>>

[d2weber]

I found a similar discussion here, but in my case it's about the return type.
I'm trying to return impl Iterator<Item = Box<dyn Iterator<Item = i32>>> from a function. What am I doing wrong to make f2 compile?

use std::iter::once;
// This works..
fn f1() -> Box<dyn Iterator<Item = i32>> {
    Box::new(once(1))
}
// This doesn't compile
fn f2() -> impl Iterator<Item = Box<dyn Iterator<Item = i32>>> {
    once(Box::new(once(1)))
}

[jofas]

Hmm, looks like explicit coercion is needed to give the compiler an extra hint that it can and needs to coerce Box<Once<{integer}>> to Box<dyn Iterator<Item = i32>>:

use std::iter::once;
// This works..
fn f1() -> Box<dyn Iterator<Item = i32>> {
    Box::new(once(1))
}
// This doesn't compile
fn f2() -> impl Iterator<Item = Box<dyn Iterator<Item = i32>>> {
    once(Box::new(once(1)) as _)
}

Playground.

[jhoobergs]

It also works if you call f1 in f2.

use std::iter::once;
// This works..
fn f1() -> Box<dyn Iterator<Item = i32>> {
    Box::new(once(1))
}
// This also compiles
fn f2() -> impl Iterator<Item = Box<dyn Iterator<Item = i32>>> {
    once(f1())
}

[d2weber]

Thank you very much, exactly what I was looking for. I revisited the chapter in the rust book about coercion. Interesting that _ can be used here.

[jofas]

Yes, a neat little trick @quinedot showed me :

Type inference fails for collection of trait objects

I imagine there's a tradeoff here, as we don't want this to stop compiling due to the compiler never being sure if it should coerce or not: fn foo() { let mut v = Vec::new(); v.push(Box::new(D1)); println!("{v:?}"); } ...but I'm not familiar enough with the compiler to do more than speculate. By the way, signaling that things may not be what they seem (i.e. where a coercion is required) also results in a successful compilation.

I guess you can use the _ placeholder here, because the compiler can infer the type it should coerce to from your function signature's return type. It just needs a nudge to do the coercion, because of the added indirection from the outer call to once. The topic I linked was me struggling to do trait object coercion with collections, which boils down to the same behaviour of Rust's type inference that you experienced with your problem here, I'd say.

[d2weber]

Thanks for the link. Seeing another example makes the case even more clear.