One/two lifetimes for struct with one reference to a reference containing struct?

[jgarvin]

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

struct BarV1<'a, 'b> {
    foo: &'a Foo<'b>
}

struct BarV2<'a> {
    foo: &'a Foo<'a>
}

Is there any situation where BarV1 will work but BarV2 will not?

[alice]

Well, basically, to construct a value like this, you need the inner lifetime to be shortenable so you can convert from &'short Foo<'long> to &'short Foo<'short> and store the latter in the field. That is the case for your particular snippet, but as you can read more about here, there are various changes you might make to the struct that would break it.

Another situation where the second version wont work is if you need bar.foo.data to give you a &'long i32 rather than a &'short i32. The second version only allows &'short i32 since the field is of type &'short Foo<'short>.

[jgarvin]

@alice

Well, basically, to construct a value like this

Like which? BarV1?

@alice

you need the inner lifetime to be shortenable

Which lifetime is the "inner" one?

[alice]

@jgarvin

@alice

Well, basically, to construct a value like this

Like which? BarV1?

BarV2

@jgarvin

@alice

you need the inner lifetime to be shortenable

Which lifetime is the "inner" one?

The one I called 'long.

[jgarvin]

@alice

That is the case for your particular snippet, but as you can read more about here, there are various changes you might make to the struct that would break it.

I just read that doc again but it's a little brain twisty. I'm not sure what it means to break it without any context of how the struct is used. Or are you saying I could add fields that would make rustc reject the declaration of my struct without even looking at places where it's used?

@alice

Another situation where the second version wont work is if you need bar.foo.data to give you a &'long i32 rather than a &'short i32 . The second version only allows &'short i32 since the field is of type &'short Foo<'short> .

This I think I understand. It's easiest for me to see if I consider a Foo<'static> made on the stack. Ideally foo.bar.data would give &'static i32, but if Bar is generic on only one lifetime it will get the stack one instead of static.

[alice]

@jgarvin

@alice

That is the case for your particular snippet, but as you can read more about here, there are various changes you might make to the struct that would break it.

I just read that doc again but it's a little brain twisty. I'm not sure what it means to break it without any context of how the struct is used. Or are you saying I could add fields that would make rustc reject the declaration of my struct without even looking at places where it's used?

No, the declaration will be valid, but creating a value of such a type (e.g. if the reference in bar is mutable) can be quite difficult.

@jgarvin

@alice

Another situation where the second version wont work is if you need bar.foo.data to give you a &'long i32 rather than a &'short i32 . The second version only allows &'short i32 since the field is of type &'short Foo<'short> .

This I think I understand. It's easiest for me to see if I consider a Foo<'static> made on the stack. Ideally foo.bar.data would give &'static i32 , but if Bar is generic on only one lifetime it will get the stack one instead of static.

Indeed. With two lifetimes you could get an &'static i32 back out, but you can't with one lifetime.

[jgarvin]

Got it, thanks!