Here are the rules:

1. Every reference as a parameter gets its own lifetime parameter. There is only one in this case.

2. If there is exactly one, then every possible lifetime in the return type is assigned to it.

3. If there are multiple parameters, but it's a method, not a free function, then the lifetime assigned to self is assigned to all outputs.

This is written in a bit of an abstract way, but, #2 there describes this function: we have one input, so we assign the same lifetime to all outputs, and there's only one. This means that it's not 'static, and in fact, it would fail to compile if it assumed that.

The original RFC, if you're curious https://rust-lang.github.io/rfcs/0141-lifetime-elision.html

(And, I actually think there's been some tweaks over time; if you have no inputs, the outputs can turn into 'static... the core of it is these three things though. Oh yeah, that is in the reference, which is the up to date spec, https://doc.rust-lang.org/reference/lifetime-elision.html; I linked the RFC for historical reference because it's interesting, and has some neat stats.)

This leaves the only remaining possibility that references in the return type must have the same lifetime as references in function's arguments. Without a GC, or leaking memory, you can't make a Rust reference/lifetime out of thin air, so there's always such relationship.

When a function takes multiple arguments by reference, the compiler will ask to disambiguate which one is used for the return type. Borrow checker intentionally checks borrowing against function prototypes, not function bodies.

- Each elided lifetime in the parameters becomes a distinct lifetime parameter.

- If there is exactly one lifetime used in the parameters (elided or not), that lifetime is assigned to all elided output lifetimes.

So, Since the signature has one `&str` as a parameter, the lifetime is assigned to the output lifetime also per these rules.

[1]: https://doc.rust-lang.org/reference/lifetime-elision.html

(Edited to improve formatting)

  // this function foo
  fn foo(s: &str) -> &str {
      &s[0..1]
  }
  
  // is equivalent to this function
  fn foo_desugared<'a>(s: &'a str) -> &'a str {
      &s[0..1]
  }
  
  // this works too because the lifetime of "" is 'static because
  // it is a str that lives in the .data segment, which will live for "any 'a"
  fn bar(s: &str) -> &str {
      &""
  }
  
  fn main() {
      // as shown here
      bar(&String::new());
  }
  
  // but this won't work, because `x` gets `drop`ed at the end of `baz`
  fn baz(x: &str) -> &str {
      let x = String::new();
      &x
  }

Keep in mind that lifetimes have the opposite behavior of generic types. A T: Trait type parameter means "something that implements at least Trait, but might implement other things that you won't have access to", while an &'a returned borrow means "something that lives at least up to 'a, but might live less".

  fn foo(bar: &x) -> &y

  fn foo<'a>(bar: &'a x) -> &'a y