Lifetimes in closure return values are inferred to be 'static, unlike with functions

[ftxqxd]

let x: || -> &str = || "hello"; // fine
fn x() -> &str { "hello" } // error

This is a result of lifetime elision not existing for closures. (Should it?) This was the only backwards-incompatible part of lifetime elision, and so for backwards-compatibility lifetime annotations should be required for closure types as well, in case lifetime elision is ever added to closures. Also, it’d be more consistent with normal functions.

This applies to return type annotations in closure expressions, too: let x = || -> &str "hello" also compiles without an explicit lifetime annotation.

[pnkfelix]

We need to firm up and/or define our semantics here, for either or both of unboxed and boxed closures. Assigning P-backcompat-lang, 1.0.

[nikomatsakis]

There is some weirdness here. There are a couple of things interacting.

One part is that when you omit lifetimes within a fn body, we usually will insert defaults.

Another part is that there is lifetime elision within fn signatures. It is not entirely clear how this interacts with omitted lifetimes. Often the compiler can infer something, but not always, particularly not around bound lifetimes. I suspect we should give the lifetime elision rules priority, but I am not certain.

[ftxqxd]

How would this interact with the unboxed closure traits? For consistency’s sake, it would be nice to be able to use Fn(&int) -> &int as a trait bound and not have to specify any lifetimes, as fn(&int) -> &int doesn’t require any either.

[nikomatsakis]

@P1start I think the same rules apply in both cases

[nikomatsakis]

ok, I think we should use the lifetime elision rules precedence, meaning that omitted lifetimes in fn signatures turn into late-bound regions, not fresh inference variables. This does mean that there is no way to explicitly "opt out" of that today, but at worst I think we ought to add one, and I suspect it will be rarely desired, since you could always leave off the type annotation entirely. (The same treatment should be true of explicitly labeling the types || expressions.)

[nikomatsakis]

Dup of #18992