3 ms·

What are the "arbitrarily complicated" cases of lifetime annotations? They cannot grow beyond one lifetime (and up to one compilation error) per variable or par

What are the "arbitrarily complicated" cases of lifetime annotations? They cannot grow beyond one lifetime (and up to one compilation error) per variable or parameter or function return value.

ameliaquining 2y ago
Mostly involving structs. Someone at work once posted the following, as a slightly-modified example of real code that they'd actually written: pub struct Step<'a, 'b> { pub name: &'a str, pub stage: &'b str, pub is_last: bool, } struct Request<'a, 'b, 'c, 'd, 'e> { step: &'a Step<'d, 'e>, destination: &'c mut [u8], size: &'b Cell<Option<usize>>, } To be sure, they were seeking advice on how to simplify it, but I imagine those with a more worse-is-better technical sensibility arguing that a language simply should not allow code like that to ever be written. I also hear that higher-ranked trait bounds can get scary even within a single function signature, but I haven't had cause to actually work with them.
- steveklabnik 2y ago
  In general, you can usually simplify the first one to have one lifetime for both, and in the second, you’d probably want two lifetimes, one for destination and the others all shared. Defaulting to the same lifetime for everything and then introducing more of them when needed is better than starting with a unique lifetime for each reference. I think you two are ultimately talking about slightly different things, your parent is trying to point out that, even if this signature is complex, it can’t get more complex than this: one lifetime per reference means the complexity has an upper bound.
- HelloNurse 2y ago
  But you are specifying that all members of Request except step.is_last have arbitrary unrelated lifetimes (shouldn't some of them be unified?) and you are simply exposing these lifetime parameters to Request client code like you would expose C++ template parameters: a trivial repetition that is easy to read, write and reason about.

What are the "arbitrarily complicated" cases of lifetime annotations? They cannot grow beyond one lifetime (and up to one compilation error) per variable or parameter or function return value.

ameliaquining 2y ago

Mostly involving structs. Someone at work once posted the following, as a slightly-modified example of real code that they'd actually written: pub struct Step<'a, 'b> { pub name: &'a str, pub stage: &'b str, pub is_last: bool, } struct Request<'a, 'b, 'c, 'd, 'e> { step: &'a Step<'d, 'e>, destination: &'c mut [u8], size: &'b Cell<Option<usize>>, } To be sure, they were seeking advice on how to simplify it, but I imagine those with a more worse-is-better technical sensibility arguing that a language simply should not allow code like that to ever be written. I also hear that higher-ranked trait bounds can get scary even within a single function signature, but I haven't had cause to actually work with them.

steveklabnik 2y ago
In general, you can usually simplify the first one to have one lifetime for both, and in the second, you’d probably want two lifetimes, one for destination and the others all shared. Defaulting to the same lifetime for everything and then introducing more of them when needed is better than starting with a unique lifetime for each reference. I think you two are ultimately talking about slightly different things, your parent is trying to point out that, even if this signature is complex, it can’t get more complex than this: one lifetime per reference means the complexity has an upper bound.
HelloNurse 2y ago
But you are specifying that all members of Request except step.is_last have arbitrary unrelated lifetimes (shouldn't some of them be unified?) and you are simply exposing these lifetime parameters to Request client code like you would expose C++ template parameters: a trivial repetition that is easy to read, write and reason about.