`self`-receiving trait function behaves different than `drop` when GATs are involved

[tingerrr]

Here's an interesting issue I ran into when writing code that involves GATs.

trait Provide {
    type State<'a>
    where
        Self: 'a;

    fn provide(&self) -> Self::State<'_>;
}

trait Consume {
    fn consume(self);
}

// Holds T, but needs to create T::State in its ctor.
struct Holder<T>(T);
impl<T> Holder<T> {
    fn use_and_hold<'a>(val: T) -> Self
    where
        T: Provide + 'a,
        T::State<'a>: Consume,
    {
        let state = val.provide();
        // drop(state);
        state.consume();

        Holder(val)
    }
}

(playground)

Which emits two errors

• One saying that val does not live long enough for the call to state.consume(),
• and another saying that it cannot move out of val at Holder(val) because it is still borrowed.

The whole diagnostic is included further down.

If you comment out the line with state.consume(); and instead add drop(state); it compiles. As far as I know, these should behave exactly the same as the free drop function is nothing special. The only difference I could see was the T: Destruct bound on drop in rust-analyzer (1.95 nightly, see below), but this can hardly be it, can it?

Somewhat tangentially: While minimizing this from my actual code, I didn't have the T: 'a bound initially. I noticed that it was needed only after I removed an associated type from Consume which was used in the return type of use_and_hold. The additional diagnostic that is shown when you remove the T: 'a bound is not emitted when the return type of use_and_hold more complex. I don't know if this is directly related to this problem, but here's an example of it.

Meta

I initially ran into this on 1.89 stable:

rustc 1.89.0 (29483883e 2025-08-04)
binary: rustc
commit-hash: 29483883eed69d5fb4db01964cdf2af4d86e9cb2
commit-date: 2025-08-04
host: x86_64-unknown-linux-gnu
release: 1.89.0
LLVM version: 20.1.7

I've also tested this with 1.95 nightly:

rustc 1.95.0-nightly (f134bbc78 2026-01-24)
binary: rustc
commit-hash: f134bbc78dac04a17324341a8d4a15a6930d81a7
commit-date: 2026-01-24
host: x86_64-unknown-linux-gnu
release: 1.95.0-nightly
LLVM version: 21.1.8

Complete Diagnostic

❯ cargo c
    Checking foo v0.1.0 (/home/tinger/foo)
error[E0597]: `val` does not live long enough
  --> src/lib.rs:23:21
   |
18 |     fn use_and_hold<'a>(val: T) -> Self
   |                     --  --- binding `val` declared here
   |                     |
   |                     lifetime `'a` defined here
...
23 |         let state = val.provide();
   |                     ^^^ borrowed value does not live long enough
24 |         // drop(state);
25 |         state.consume();
   |         --------------- argument requires that `val` is borrowed for `'a`
...
28 |     }
   |     - `val` dropped here while still borrowed

error[E0505]: cannot move out of `val` because it is borrowed
  --> src/lib.rs:27:16
   |
18 |     fn use_and_hold<'a>(val: T) -> Self
   |                     --  --- binding `val` declared here
   |                     |
   |                     lifetime `'a` defined here
...
23 |         let state = val.provide();
   |                     --- borrow of `val` occurs here
24 |         // drop(state);
25 |         state.consume();
   |         --------------- argument requires that `val` is borrowed for `'a`
26 |
27 |         Holder(val)
   |                ^^^ move out of `val` occurs here
   |
help: if `T` implemented `Clone`, you could clone the value
  --> src/lib.rs:17:6
   |
17 | impl<T> Holder<T> {
   |      ^ consider constraining this type parameter with `Clone`
...
23 |         let state = val.provide();
   |                     --- you could clone this value

Some errors have detailed explanations: E0505, E0597.
For more information about an error, try `rustc --explain E0505`.
error: could not compile `foo` (lib) due to 2 previous errors

The line numbers may be off, I added #![allow(dead_code)] locally.

[tingerrr]

The only thing I found before this was #105878, but I don't know if this has the same cause because the workaround with T: 'static did not fix it.

[QuineDot]

If you comment out the line with state.consume(); and instead add drop(state); it compiles. As far as I know, these should behave exactly the same as the free drop function is nothing special.

You can only call .consume() if the Consume bound is met. You only stipulated that the bound is met for lifetime 'a. So with the call to .consume() being present, you must borrow the local val for 'a in the call to .provide(). But lifetimes nameable in the function body (such as 'a) always outlive the function body, so you can never borrow a local for 'a.

Calling drop, in contrast, requires no specific lifetime.

The fix is usually a higher-ranked trait bound (for<'a> ...):

-   fn use_and_hold<'a>(val: T) -> Self
+   fn use_and_hold(val: T) -> Self
    where
-        T: Provide + 'a,
-        T::State<'a>: Consume,
+        T: for<'a> Provide<State<'a>: Consume>,
    {

If that causes problems elsewhere in your code, it may be due to poor interaction between GATs and HRTBs.

[tingerrr]

But lifetimes nameable in the function body (such as 'a) always outlive the function body, so you can never borrow a local for 'a

Ah, this seems obvious to me in hindsight, but it is not something that I had actively internalized.

Considering that this is more of an issue on my side, I wonder how feasible it would be to improve the diagnostics here? I'll test this locally with my actual code and report back. I expect that it will work there too, so once I've tested it we can either close this or make it about improving the diagnostic.

[tingerrr]

I seem to be running into the one type more generic than the other mentioned in Sabrina's blog when I actually try to implement this, I'll look at opening a forum post as this seems mostly like a skill issue on my side. A more accurate example of what I have in my code is this (note that I had to either name the type C: Consume or lifetime 'b in use_and_hold to access T::State<'b>::Error).

I'm unsure if this is a skill issue on my side or if Rust can't express this at the moment.

[QuineDot]

When you use the generic type variable C here:

        T: for<'a> Provide<State<'a> = C>,

You're saying the associated type must be the same for all 'a -- i.e. it cannot contain 'a. That's not true for ProvideImpl.

to access T::State<'b>::Error

It presumably is okay to require that the error is the same type for all 'a (as otherwise you couldn't return it -- if it contained 'a, it would contain a borrow of a local in use_and_hold):

impl<T> Holder<T> {
    fn use_and_hold<E>(val: T) -> Result<Self, E>
    where
        T: for<'a> Provide<State<'a>: Consume<Error = E>>,
    {

That compiles.

[tingerrr]

Yes, indeed! Thank you! I suppose triage can close this then or mroph it to be about improving the diagnostics, they were rather generic.

Fwiw, I wans't even aware you could add such an inner bound within a bound without introducing a new type parameter to use.

[QuineDot]

Fwiw, I wans't even aware you could add such an inner bound within a bound without introducing a new type parameter to use.

Introduced in 1.79, but you can avoid that feature if you need to (for MSRV or whatever).

impl<T> Holder<T> {
    fn use_and_hold<E>(val: T) -> Result<Self, E>
    where
        T: Provide,
        for<'a> T::State<'a>: Consume<Error = E>,