-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
Comments
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. |
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. |
How would this interact with the unboxed closure traits? For consistency’s sake, it would be nice to be able to use |
@P1start I think the same rules apply in both cases |
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 |
Dup of #18992 |
…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.
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.The text was updated successfully, but these errors were encountered: