Inferred lifetimes?

[sighoya]

Reviving thread: Why can lifetimes not be inferred? - #19 by ExpHP

@Yandros

For your example there are already two different lifetime annotations that work:

• unified input lifetime:

fn longest<'a> (x: &'a str, y: &'a str) -> &'a str

• minimum lifetime on output (unified output)

fn longest<'a, 'x: 'a, 'y: 'a> (x: &'x str, y: &'y str) -> &'a str

Wouldn't the second describe all possibilities whereas the first is too restrictive in what longest can offer.
I understand though that we need explicit annotations in signatures because they are decoupled from their value (m to n relationship).

What I mean is: Can we just assume the worst case for values (functions,impls) or is this not enough in some cases?

[SkiFire13]

I don't think there's any difference in the example, you can still pass any string slice you want and the returned value lifetime will always be bounded by the shortest lifetime.

There are however some cases where not using different lifetimes will restrict your function more than it should. For example HashSet::difference and BTreeSet::difference don't separate the lifetimes of self and other and this results in the iterator's items being references borrowing from both parameters, while in reality they borrow only from self. See rust-lang/rust#73788

[sighoya]

@SkiFire13

There are however some cases where not using different lifetimes will restrict your function more than it should.

Therefore, my question, should we restrict function definitions at all?

[2e71828]

@sighoya

Therefore, my question, should we restrict function definitions at all?

This sort of language design question / proposal more properly belongs on the internals forum, as it's not really about how to use Rust today.

I'm not super familiar with this part of the design space, but proposals to automatically infer things generally run into one of these problems:

• They can't be implemented without breaking existing code, which requires a very strong justification.
• They strike the "wrong" balance between allowing crate authors to make non-breaking changes and crate users to do useful things.
• The discussion about the feature was closed long ago, and the language designers would rather spend their time on new problems instead of rehashing old ones.

[sighoya]

Well I thought such a change belongs to the lifetime elision camp, but yes you are generally right about that being a more internal forums related question.