Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
ftxqxd opened this issue Oct 10, 2014 · 6 comments
Milestone

Comments

@ftxqxd
Copy link
Contributor

ftxqxd commented Oct 10, 2014

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
Copy link
Member

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.

@pnkfelix pnkfelix added this to the 1.0 milestone Oct 16, 2014
@nikomatsakis
Copy link
Contributor

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.

@aturon aturon mentioned this issue Oct 16, 2014
47 tasks
@ftxqxd
Copy link
Contributor Author

ftxqxd commented Oct 18, 2014

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
Copy link
Contributor

@P1start I think the same rules apply in both cases

@nikomatsakis
Copy link
Contributor

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
Copy link
Contributor

Dup of #18992

lnicola pushed a commit to lnicola/rust that referenced this issue Aug 29, 2024
…s, r=Veykril

Test for word boundary in `FindUsages`

This speeds up short identifiers search significantly, while unlikely to have an effect on long identifiers (the analysis takes much longer than some character comparison).

Tested by finding all references to `eq()` (from `PartialEq`) in the rust-analyzer repo. Total time went down from 100s to 10s (a 10x reduction!).

Feel free to close this if you consider this a non-issue, as most short identifiers are local.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants