Hacker News Reader

Comment by mplanchard | Hacker News Reader

You’re passing in two references and returning a reference.

The compiler knows the returned reference must be tied to one of the incoming references (since you cannot return a reference to something created within the function, and all inputs are references, the output must therefore be referencing the input). But the compiler can’t know which reference the result comes from unless you tell it.

Theoretically it could tell by introspecting the function body, but the compiler only works on signatures, so the annotation must be added to the function signature to let it determine the expected lifetime of the returned reference.

View on HN

> Theoretically it could tell by introspecting the function body, but the compiler only works on signatures

Note that this is an intentional choice rather than a limitation, because if the compiler analyzed the function body to determine lifetimes of parameters and return values, then changing the body of a function could be a non-obvious breaking API change. If lifetimes are only dependent on the signature, then its explicit what promises you are or are not making to callers of a function about object lifetimes, and changing those promises must be done intentionally by changing the signature rather than implicitly.

> changing the body of a function could be a non-obvious breaking API change

This. Many trival changes breaks API. This is not ideal for library developers.

You can argue it is broken already, but this is forcing the breakage onto every api caller, not just some broken caller.

Oh yes, I didn’t mean to make it sound like a problem. I personally strongly prefer signature-based typing vs like in Typescript where you can easily be returning an entirely unintentional type and not realize it until you try to use it in an explicitly typed context down the line.

I also imagine it’s much faster for the type-checking pass of the compiler to just look at the signatures.

Reply on news.ycombinator.com