A Better Lifetime Elision Rules?

⚓ Rust    📅 2025-06-25    👤 surdeus    👁️ 6      

surdeus

Warning

This post was published 48 days ago. The information described in this article may have changed.

Hey, I started to learn rust lately. I'm trying to understand how lifetimes work and interact with the ownership system. From my understanding:

  1. Each variable has its own lifetime.
  2. The lifetime is from the definition of the variable untill is last (possible) use or the end of the block (is there a difference?)
  3. Rust performs implicit conversion when possible and needed, this conversion only "shrinks" the lifetime.

My questions are:

  1. What happens in the borrow checker, assuming a call to a function with two variables that returns one of them, from the borrow checker's perspective, are both variables borrowed, and permissions regained only after the last use of the return value?
  2. In the elision rules, Why can't we define a better version that always assigns one generic lifetime for all variables? Then we could always return a value without needing to explicitly write that there is only one lifetime for all inputs/outputs. In cases of an unconditional return value, we could still specify a different lifetime for the returned variable and get the benefits of a larger lifetime. Currently, we need to explicitly specify the lifetime in both cases.

5 posts - 4 participants

Read full topic

🏷️ rust_feed