6

If I write the code below, I get error[E0309]: the parameter type 'T' may not live long enough.

struct Function<T> {
    f: fn() -> T,
}

struct FunctionRef<'f, T> {
    f: &'f Function<T>,
}

This fixes the error:

struct FunctionRef<'f, T: 'f> {
    f: &'f Function<T>,
}

However, as far as I can tell, T is not bound on the lifetime 'f. Indeed, T is a new object created when the function of type fn () -> T is run.

Where am I missing something?

hellow
  • 12,430
  • 7
  • 56
  • 79
Olivier
  • 773
  • 9
  • 14
  • This is effectively the same question as [The compiler suggests I add a 'static lifetime because the parameter type may not live long enough, but I don't think that's what I want](https://stackoverflow.com/questions/40053550/the-compiler-suggests-i-add-a-static-lifetime-because-the-parameter-type-may-no): `T: 'f` does not mean that *every* `T` lives for at least `'f`, it means that `T` cannot contain any references with a lifetime less than `'f`. – trent Nov 20 '18 at 12:49
  • 1
    The only lifetime bound that makes sense here is using `T: 'static`. Since the function pointed to by `f` does not take any arguments, it can't really return a reference with any other lifetime than the static lifetime. (The situation would be different if you changed the type of `f` to a generic type `F: Fn() -> T`, since this would also allow for closures, which can return captured references that have different lifetimes.) – Sven Marnach Nov 21 '18 at 09:28

1 Answers1

4

Short answer: You need T: 'f because T may contains field that hold references and fn() -> T is covariant over T.

To simplify things may help to understand ...

For a moment substitute fn() -> T with T, because for me it is more simple to explain what it is happening with lifetimes. See the Note below why with this substitution does not change the lifetime related error.

struct Function<T> {
    f: T,
}

struct FunctionRef<'f, T> {
    f: &'f Function<T>,
}

This lead to the same error[E0309]: the parameter type 'T' may not live long enough error.

FunctionRef instances cannot outlive the reference it holds in f field: you declare a generic lifetime parameter 'f inside angle brackets and then you use 'f as an annotation inside the struct body. See also the book.

But FunctionRef::f depends on a type parameter T. The explicit constraint T: 'f guarantee that T instances does not outlive references holded by T and FunctionRef does not outlive FunctionRef::f.

If it can help to understand substitute the generic T with a specific Foo type:

struct Foo<'a> {
    n: &'a i32,
}

struct FunctionRef<'f, 'a: 'f> {
    f: &'f Foo<'a>,
}

You need to constraint lifetime 'a to be valid at least as long as 'f lifetime, otherwise memory safety rules would be violated.

Note

I have considered the case f: T equivalent of f: fn() -> T because such type constructor is covariant over T.

To grasp the meaning of fn() -> T is covariant over T, consider this struct:

struct Foo<'a> {
    v: &'a i32
}

In this case is safe to assign to v a value with a lifetime "bigger" than 'a, for example:

let ref_value: &'static i32 =  &100;
let foo = Foo { v: ref_value};

Now the same holds for the following struct:

struct Function<'a> {
    f: fn() -> &'a i32
}

The field f expects a function that returns a &i32 that outlive 'a.

In this case it is safe to pass a function that returns a &i32 with a "bigger" lifetime, for example:

fn my_f() -> &'static i32 {
    &100
}

fn main() {
    let foo = Function { f: my_f};
}

There is quite a lot of type theory behind this, see the nomicom for a detailed explanation.

Community
  • 1
  • 1
attdona
  • 17,196
  • 7
  • 49
  • 60
  • Thank you. I understand your statement and I agree with it. However it does not answer my question. In the case you are showing I agree that `T` should be live longer than the lifetime`'f`. However, I still do not understand why the statement "`T` should be live longer than the lifetime`'f" is true for the case I presented in my question. You say "This error has nothing to do with the fact that Function::f is a function". To this I want to ask "Why?". Sorry if I am dumb. – Olivier Nov 20 '18 at 09:54
  • I see your doubt, I've added a note. – attdona Nov 20 '18 at 10:17