Free functions and trait methods that return impl Trait capture lifetimes differently (edition 2021)

[golddranks]

I tried this code:

trait MyTrait {}
impl MyTrait for () { }

trait GetMyTrait {
    fn get(&self) -> impl MyTrait;
}

struct MyStruct;
impl GetMyTrait for MyStruct {
    fn get(&self) -> impl MyTrait {
        return ();
    }
}

fn get(_: &MyStruct) -> impl MyTrait {
    return ();
}

fn main() {
    Some(MyStruct).map(|x| get(&x)); // Free function: passes compiler
    Some(MyStruct).map(|x| x.get()); // Trait method: doesn't pass
}

I expected to see this happen: Either both calls to GetMyTrait::get and get should pass or fail. With the new 2024 capture rules, I think they should fail without use<>, and with the old rules (from RFC3617):

In Rust 2021 and earlier editions, for RPIT on bare functions and on inherent functions and methods, lifetime parameters are not implicitly captured unless named in the bounds of the opaque.

So, currently, it should pass.

Instead, this happened: The free function doesn't capture the lifetime of &self in the return type impl MyTrait, so the map method passes. The trait method, however, seems to capture the lifetime, causing map to fail.

Meta

rustc --version --verbose:

rustc 1.82.0 (f6e511eec 2024-10-15)
binary: rustc
commit-hash: f6e511eec7342f59a25f7c0534f1dbea00d01b14
commit-date: 2024-10-15
host: aarch64-apple-darwin
release: 1.82.0
LLVM version: 19.1.1

(The bug happens also on nightly.)

[golddranks]

I just checked that this has been existed from the beginning circa 1.75,0, since impl Traits could be used in trait definitions. So it's not a regression. However, as use<> is still unstable in traits, and impl Trait is unusable in associated types, there doesn't seem to be a great way to work around this.

[theemathas]

This appears to be intended as per RFC 3498?

(See appendices A and C for justification.)

[golddranks]

Ah, indeed, the matrix of capture effects is also very helpful. So it is not a bug; my bad on thinking that RPITIT would obey the same rules as inherent methods and free functions. I guess that the lack of expressiveness here just has to wait for stabilization of use<> in traits then. I'm going to close this; thanks!