Repository navigation
Annotating higher-ranked lifetimes on closures is arduous #58052
Description
Executive summary: If you want to make a closure returning a higher-ranked lifetime, you need to use a helper like fn annotate<T,F>(f: F) -> F where F: Fn(&T) -> &T { f }. We could probably do better.
Spawned off of #22557 (comment) (and possibly a duplicate of #22340 )
Consider this code (play):
fn main() {
let f = |x: &i32| x;
let i = &3;
let j = f(i);
}It doesn't compile. And its diagnostic is pretty hard to understand.
You can see an explanation from @nikomatsakis about why it doesn't compile here: #22557 (comment)
With #![feature(nll)], it still doesn't compile; the diagnostic is slightly better:
error: lifetime may not live long enough
--> src/main.rs:4:23
|
4 | let f = |x: &i32| x;
| - - ^ returning this value requires that `'1` must outlive `'2`
| | |
| | return type of closure is &'2 i32
| let's call the lifetime of this reference `'1`
The aforementioned explanation claims that adding a return type will get it to compile. But when I tried that, it did not work, both with and without #![feature(nll)] (play, which includes NLL since I like its diagnostic here better):
fn main() {
let f = |x: &i32| -> &i32 { x };
let i = &3;
let j = f(i);
}yields (and we'll leave #58053 in its own bug):
error: lifetime may not live long enough
--> src/main.rs:4:33
|
4 | let f = |x: &i32| -> &i32 { x };
| - - ^ returning this value requires that `'1` must outlive `'2`
| | |
| | return type of closure is &'2 i32
| let's call the lifetime of this reference `'1`
So what gives? Well, I think when @nikomatsakis claimed that an explicit return type would work, they were assuming that an explicit return type would cause lifetime elision rules to apply such that the same lifetime would be provided for the input and output reference-types on f. But as we saw in #56537, lifetime elision rules do not apply to closure return type annotations.
So what we want is to say that we have a lifetime parametric closure, with a type something like for<'a> Fn(&'a i32) -> &'a i32. But no, that's not a type, its a trait bound, so this does not work either (play):
fn main() {
let f: for<'a> Fn(&'a i32) -> &'a i32 = |x| x;
let i = &3;
let j = f(i);
}yields:
error[E0308]: mismatched types
--> src/main.rs:4:45
|
4 | let f: for<'a> Fn(&'a i32) -> &'a i32 = |x| x;
| ^^^^^ expected trait std::ops::Fn, found closure
|
= note: expected type `dyn for<'a> std::ops::Fn(&'a i32) -> &'a i32`
found type `[closure@src/main.rs:4:45: 4:50]`
error[E0277]: the size for values of type `dyn for<'a> std::ops::Fn(&'a i32) -> &'a i32` cannot be known at compilation time
--> src/main.rs:4:9
|
4 | let f: for<'a> Fn(&'a i32) -> &'a i32 = |x| x;
| ^ doesn't have a size known at compile-time
|
= help: the trait `std::marker::Sized` is not implemented for `dyn for<'a> std::ops::Fn(&'a i32) -> &'a i32`
= note: to learn more, visit <https://doc.rust-lang.org/book/ch19-04-advanced-types.html#dynamically-sized-types-and-the-sized-trait>
= note: all local variables must have a statically known size
= help: unsized locals are gated as an unstable feature
An approach that does work is to feed in the trait bound explicitly via a helper function, like this (play):
fn annotate<T,F>(f: F) -> F where F: Fn(&T) -> &T { f }
fn main() {
let f = annotate(|x| x);
let i = &3;
let j = f(i);
assert_eq!(*j, 3);
}But that seems like a pretty arduous way to encode a relatively simple pattern. If you look at #22340 (comment), you can see others have suggested syntaxes like for <'a> |x: &'a i32| -> &'a i32 { x }, (where the for <'a> CLOSURE_EXPR is the new interesting expression form), which would be more convenient for addressing cases like ths.
Activity
[-]Annotating higher-ranked lifetimes on closures is arduous.[/-][+]Annotating higher-ranked lifetimes on closures is arduous[/+]Centril commentedon Feb 2, 2019
I think that:
should all be equivalent (well ~ the opaque nature of
impl ...) and Just Work.ISTM that
for<'a>isn't properly inferred when youletbind a closure unlike when you pass it immediately to a function. I see no good justification for that right now.As for introducing
for<'a> |x: &'a| ...it's on my TODO list wrt.for<T: Debug>and generic closures in general. I've been working on a draft but haven't messed with it for a while.fredericvauchelles commentedon Apr 16, 2019
👍 It will be very nice to have higher-ranked lifetimes for closure. (Very nice to write easily schedulable tasks)
Use function wrapper to annotate lifetimes on closures.
tema3210 commentedon May 22, 2021
Is there any plans for smth. like
for<'a,'b: 'a> impl Fn(&'a T)->U? (syntax is really bad, but still) Because we don't have any way to say "for all lifetimes that are shorter (or longer) then 'x ..." i.e. bounded quantification for lifetimes?.nikomatsakis commentedon May 24, 2021
We don't presently have clear plans to support this syntax, although we are actively at work on extending rustc internally to support that sort of thing.
jinohkang-theori commentedon Apr 13, 2023
#98705 implemented the closure lifetime binder syntax. However, the syntax requires the user to fully specify the type signature, so I'd argue that using higher-ranked lifetimes on closures are still tedious.
theemathas commentedon Jun 9, 2024
Another use case where one runs into this issue:
Compile error
However, for some reason, annotating the type with
|x: &i32|makes the code compile.The workaround that compiles