Unclear compiler error when `impl Trait` return value captures non-'static argument

[ramosbugs]

(cc @estebank)

I tried this code (the explicit 'static lifetime is unnecessary but emphasizes the implicit 'static requirement of impl Trait):

fn foo<T>(a: T) -> impl Iterator<Item = String> + 'static
where
    T: std::fmt::Display
{
    std::iter::once(a.to_string())
}

fn bar(a: &str) -> impl Iterator<Item = String> + 'static {
    foo(a)
}

See playground.

I expected to see this happen:

Successful compilation or a clear error message suggesting that impl Trait can't be used in this way due to the non-'static lifetime of foo's argument a.

Instead, this happened:

error[E0759]: `a` has an anonymous lifetime `'_` but it needs to satisfy a `'static` lifetime requirement
 --> src/lib.rs:9:9
  |
8 | fn bar(a: &str) -> impl Iterator<Item = String> + 'static {
  |           ---- this data with an anonymous lifetime `'_`...
9 |     foo(a)
  |         ^ ...is captured here...
  |
note: ...and is required to live as long as `'static` here
 --> src/lib.rs:8:20
  |
8 | fn bar(a: &str) -> impl Iterator<Item = String> + 'static {
  |                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
help: consider changing the `impl Trait`'s explicit `'static` bound to the lifetime of argument `a`
  |
8 | fn bar(a: &str) -> impl Iterator<Item = String> + '_ {
  |                                                   ^^
help: alternatively, add an explicit `'static` bound to this reference
  |
8 | fn bar(a: &'static str) -> impl Iterator<Item = String> + 'static {
  |           ^^^^^^^^^^^^

foo's return value isn't dependent on a's lifetime since to_string converts it to an owned String. Returning Box<dyn Iterator<Item = String>> instead of using impl Trait fixes the error.

Neither of the compiler's suggestions are the "right" fix here, since I'd like the return value to have a 'static lifetime but don't want to require a to have one.

I think the ideal fix (to the error message) would be something along the lines of:

• a short explanation of why impl Trait doesn't allow the return value not to depend on the lifetime of a (maybe with a tracking issue if this limitation is being addressed)
• an additional suggestion to use Box<dyn Trait> and/or a concrete type

Meta

rustc --version --verbose:

rustc 1.50.0 (cb75ad5db 2021-02-10)
binary: rustc
commit-hash: cb75ad5db02783e8b0222fee363c5f63f7e2cf5b
commit-date: 2021-02-10
host: x86_64-apple-darwin
release: 1.50.0

[jyn514]

This seems similar to #79415.

[estebank]

an additional suggestion to use Box<dyn Trait> and/or a concrete type

That might be reasonable, it'll just be tricky to identify the specific cases where this action would be appropriate to try and avoid a diagnostic that is too verbose for uncommon cases.

This seems similar to #79415.

Good catch! It is a similar case, but will likely need to be handled independently. Let's not close either :)

[estebank]

There's no way currently to express that an impl Trait doesn't capture all the input lifetimes. Once type Ret<'a> = impl Trait + 'a; is stabilized you could express the behavior you're looking for, but for now the only option are the ones identified in the report (explicit type and Box<dyn Trait>).

[rami3l]

@ramosbugs @estebank

A friend of mine just encountered something similar, and I found this workaround from #34511, which seems to fit your problem here. (However, I haven't personally figured out why this works... Any help will be appreciated!)

I tried to fix your code using this method:

fn foo<T>(a: T) -> impl Iterator<Item = String> + 'static
where
    T: std::fmt::Display,
{
    std::iter::once(a.to_string())
}

// What are those?
trait Captures<'a> {}
impl<'a, T: ?Sized> Captures<'a> for T {}

fn bar1<'a>(a: &'a str) -> impl Iterator<Item = String> + 'static + Captures<'a> {
    foo(a)
}

---

Update: Now this workaround can be automatically applied via the fix_hidden_lifetime_bug.rs library.

Update: This could be resolved in language edition 2024 which will, as currently planned, allow you to use TAIT to avoid over-capturing: #115822, HackMD