Rust shouldn't suggest using a single lifetime everywhere

[theemathas]

Code

pub fn foo(x: &i32, y: &i32) -> &i32 {
    x
}

Current output

error[E0106]: missing lifetime specifier
 --> src/lib.rs:1:33
  |
1 | pub fn foo(x: &i32, y: &i32) -> &i32 {
  |               ----     ----     ^ expected named lifetime parameter
  |
  = help: this function's return type contains a borrowed value, but the signature does not say whether it is borrowed from `x` or `y`
help: consider introducing a named lifetime parameter
  |
1 | pub fn foo<'a>(x: &'a i32, y: &'a i32) -> &'a i32 {
  |           ++++     ++          ++          ++

For more information about this error, try `rustc --explain E0106`.

Desired output

...
pub fn foo<'a>(x: &'a i32, y: &i32) -> &'a i32 {
...

Rationale and extra context

The compiler is telling the user to apply the same lifetime everywhere. This is incorrect, and will make the code seemingly work, but then will fail later.

This issue of incorrectly using a single lifetime everywhere is a very common beginner pitfall, and the compiler teaching that to users does not help.

Other cases

Rust Version

Reproducible on the playground with version 1.93.0-nightly
(2025-10-29 292be5c7c05138d753bb)

Anything else?

Ideally, the compiler should be able to look at the function body to determine how to correctly annotate the lifetime. But if that's not feasible, the compiler should at least suggest annotating the lifetime only one time, with each possible place as alternatives in the suggestion.

[scottmcm]

No idea whether this is feasible, but one possibility might be to run NLL as though it had been written as

fn foo<'a, 'b, 'c>(x: &'a str, y: &'b str) -> &'c str { … }

and use the results to see which place(s) should get the separate lifetimes to match the current body.

[hkBst]

That currently gives:

error: lifetime may not live long enough
 --> src/lib.rs:1:57
  |
1 | fn foo<'a, 'b, 'c>(x: &'a str, y: &'b str) -> &'c str { x }
  |        --      -- lifetime `'c` defined here            ^ function was supposed to return data with lifetime `'c` but it is returning data with lifetime `'a`
  |        |
  |        lifetime `'a` defined here
  |
  = help: consider adding the following bound: `'a: 'c`

which is also not the right suggestion (for this example), but at least shows that the compiler has all the information to come up with a better suggestion.

[estebank]

Be aware that it is not really feasible for the compiler to identify what the correct lifetimes need to be. It can determine what the smallest subset could be, but lifetimes are not purely a compiler exclusive concept: they are a message of intent from the developer on what their API invariants are. Suggesting an overly constrained API signature is not necessarily worse than suggesting an API signature that isn't constrained enough. At some point, the user must be in the loop and make decisions that rustc won't be able to guide towards entirely.

[abh1nav10]

Any output reference whose lifetime is not inferred from the input lifetimes in the function is unbounded and we must try to bound it because otherwise it would not be possible for the compiler to check whether the thing it points to actually lives for as long as the reference is being used . The suggestion of giving different lifetimes would not be a safe alternative to have.

[QuineDot]

I feel a single lifetime actually is the correct suggestion for the specific example, as it is the most flexible for the author of the function. It also won't necessarily fail later (unlike, say, &'a mut Thing<'a>, which almost always does); it's a perfectly reasonable signature.

If two lifetimes are suggested and the body gets changed to possibly return the other input, the author will have to change the signature again for the function to compile, and this time it may break downstream callers as well (because they didn't "fail" before).