Uhm, what if I didn't want `&OtherType` to have the same lifetime? Would I then write:

    fn f<'a>(x: &'a SomeType) -> &'b OtherType

?

That would be illegal, because it only makes sense to return a reference when that reference is somehow linked to the lifetime of an input parameter.

(Or when it has a lifetime of `static`, which means the referent is stored in static memory and thus is alive for the whole program.)

What if you're looking up the input in a temporary cache of some kind, and returning a reference to the cached value? The lifetime of the input and output would not be related in that scenario, but the output would not necessarily be 'static (maybe you build a cache, run some functions, tear it all down, then build a new cache with different values and do it all again).

The lifetime would be matched to the lifetime of the cache, which has to be referred to somehow.

Ah cool, I still have a lot to learn about rust :)

You wouldn't use a reference generally, if you're thinking of creating a new independent object you'd just return that. This is for cases when your return object is a reference into your argument, for example

Yes, though this particular code would not compile because one of the lifetimes is not declared.

ah, got it. thanks!