Inspired by the clarity of the following:
... a statement I know is true.
Is it ok to say that the only reason we need to parameterize lifetimes is because it’s a compile-time analysis? Or is it because the compiler only performs the analysis “one function at a time”.
Otherwise, when lifetime types can’t be inferred (multiple possibilities), why not fail only when the caller creates the case that violates the rules?
The answer has to be more a limitation of only interpreting “one function at a time”... which means we can navigate lifetimes with more inference by combining logic under a single scope. Perhaps self-evident because each new scope creates a new opportunity to create a new lifetime type.
Bear with me. This matters because it might help better understand lifetimes - they are what they’re good for.
Part of this “churning” on lifetimes has todo with the contrast with “traditional” type parameters where the end user creates a concrete type with values that have constructors of a specific type. E.g.,
Vec<MyType> happens with
This is not the case for lifetimes. They are more like values, not a type parameter (this conflicts with my understanding that a rust type has two kind parameters to create a type, lifetime kind and type kind)
They don’t have constructors so can’t be “typed”; the best I could think of is scope as the constructor.
Lifetimes are not absolute but relative (so a single lifetime only has meaning in relation to the lifetime of the app; similarly, single scope, single lifetime type; in contrast, String means something on its own).
‘static is a value of a lifetime that lasts as long as the app (relative equality); but equating lifetimes to that of the app is likely not the best description because lifetime values only have meaning in relation to other lifetimes. So, ultimately values as “always the longest” or “always long enough” by the compiler (where many values can be qualified as such).
... lifetimes help the compiler compiler make conclusions “one function at a time”. It has no use beyond that.
GATs will work for the lifetime kind but not type kind (as best I can determine). What range of lifetimes does the new parameter enable?
‘a parameter accepts what as values?
What value can I use when there is no lifetime? (owned values); is borrow & owned “a bridge too far”
Concretely, where I had to implement many instances of a trait, where can I specify just one using a GAT?
Thanks in advance to anyone that can help me reconcile the above.