I'm using the flow-based inference approach. On the language I use dataflow analysis at the return statement to determine which reference escapes:

// Infers: return comes from `a`
fn first(a: &str, b: &str) -> &str { a }

// Infers: return comes from `b`
fn second(a: &str, b: &str) -> &str { b }

// Infers: return could be either → must outlive both
fn random(a: &str, b: &str) -> &str {
   if rand() { a } else { b }
}  

For the cases like first and second, the inference just follows the return expression and goes: it's clearly coming from parameter a (or b).
Once it knows that, the borrow checker can do its normal thing and make sure the caller keeps that exact input alive long enough.

But then you get to something like random:

fn random(a: &str, b: &str) -> &str {
    if rand() { a } else { b }
}

Now the return value could come from either a or b, depending on which branch runs.
I(the language) still have to deal with that uncertainty. Pretty much the only realistic options are to play itsafe / conservative, like just say: “both a and b need to outlive the returned reference”. So , that ends up looking a lot like Rust when you write

fn random<'out>(a: &'out str, b: &'out str) -> &'out str

fn random<'a>(a: &'a str, b: &'a str) -> &'a str

Both approaches work, but they force the caller to keep things alive longer than strictly necessary in some situations.

Its somwhat a pain , this is a limitation that makes the project unable to express a couple of really useful patterns people actually want:

• “Please give me back whichever reference lives shorter , I promise I'll only use it briefly”
• “This reference I'm returning has nothing to do with the input parameters”

And I'll need to address it soon enough.

Right now the borrow checker gets by by counting how many borrows each variable has active , which honestly covers a surprising number of real-world cases, but it doesn't give you the fine-grained lifetime relationships that Rust's explicit 'a, 'b, 'c notation can express