Hidden type captures lifetime that does not appear in bounds, but return value doesn't capture references

jun · July 11, 2023, 11:02pm

I have a function that takes an impl Trait and returns an impl Trait + 'static. The input value can be a reference, but that reference is not captured by the output.

struct Foo;

trait Input {}
impl Input for &Foo {}

trait Output {}
impl Output for () {}

// this compiles fine on its own
fn takes_generic(val: impl Input) -> impl Output + 'static { }

// this does not
fn takes_concrete<'a>(s: &'a Foo) -> impl Output + 'static {
    takes_generic(s)
}

However, I get the following error:

error[E0700]: hidden type for `impl Output + 'static` captures lifetime that does not appear in bounds

It works fine if Input is instead implemented for Foo and the argument is passed by value, but in my real code, I'd prefer not to clone the input for each call.

How can I convince Rust that that output is in fact not capturing a lifetime?

I've seen a few topics relating to this error, but not the same. I did see this issue but that seems to have been fixed in 1.69.

Playground link: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=44854d3a71a61842edc80f99d9c6977b

quinedot · July 11, 2023, 11:35pm

You need smarter return-position impl Trait that realizes the generic parameter can't be captured in the opaque return type, or you need type alias impl Trait to work around it.

github.com/rust-lang/rust

impl-trait return type is bounded by all input type parameters, even when unnecessary

opened 07:57PM - 27 Jun 17 UTC

Arnavion

A-lifetimes T-compiler A-impl-trait C-bug WG-async

``` rustc 1.20.0-nightly (f590a44ce 2017-06-27) binary: rustc commit-hash: f5…90a44ce61888c78b9044817d8b798db5cd2ffd commit-date: 2017-06-27 host: x86_64-pc-windows-msvc release: 1.20.0-nightly LLVM version: 4.0 ``` ```rust #![feature(conservative_impl_trait)] trait Future { } impl<F> Future for Box<F> where F: Future + ?Sized { } struct SomeFuture<'a>(&'a Client); impl<'a> Future for SomeFuture<'a> { } struct Client; impl Client { fn post<'a, B>(&'a self, _body: &B) -> impl Future + 'a /* (1) */ { SomeFuture(self) } } fn login<'a>(client: &'a Client, username: &str) -> impl Future + 'a { client.post(&[username]) } fn main() { let client = Client; let _f = { let username = "foo".to_string(); login(&client, &username) }; } ``` Since `SomeFuture` borrows `'a Client`, I'd expect `impl Future + 'a` to be the correct return type, but it gives this error: ``` error[E0495]: cannot infer an appropriate lifetime due to conflicting requirements --> src\main.rs:21:16 | 21 | client.post(&[username]) | ^^^^^^^^ | note: first, the lifetime cannot outlive the anonymous lifetime #1 defined on the function body at 20:1... --> src\main.rs:20:1 | 20 | / fn login<'a>(client: &'a Client, username: &str) -> impl Future + 'a { 21 | | client.post(&[username]) 22 | | } | |_^ note: ...so that expression is assignable (expected &str, found &str) --> src\main.rs:21:16 | 21 | client.post(&[username]) | ^^^^^^^^ note: but, the lifetime must be valid for the lifetime 'a as defined on the function body at 20:1... --> src\main.rs:20:1 | 20 | / fn login<'a>(client: &'a Client, username: &str) -> impl Future + 'a { 21 | | client.post(&[username]) 22 | | } | |_^ note: ...so that the type `impl Future` will meet its required lifetime bounds --> src\main.rs:20:53 | 20 | fn login<'a>(client: &'a Client, username: &str) -> impl Future + 'a { | ^^^^^^^^^^^^^^^^ error: aborting due to previous error(s) ``` - Changing `_body` to have an explicit lifetime like `_body: &'b B` where `'b` is independent of `'a` or where `'a: 'b` does not change the error. This and the original error make it seem that returning an `impl trait` is somehow causing the `_body` parameter to get the `'a` lifetime, even though it's clearly unused, let alone used in a way that it would require the `'a` lifetime. - Changing `(1)` from `impl Future + 'a` to `SomeFuture<'a>` fixes it. - Changing `(1)` from `impl Future + 'a` to `Box<Future + 'a>` and returning `Box::new(SomeFuture(self))` fixes it.

jun · July 12, 2023, 3:33pm

Dang that's an old issue! In my case I sort of got around it by changing the signature of takes_generic to use a Cow instead. Worse ux but not terrible.

Thanks!