Improve explanation of lifetimes #2584
Conversation
djmitche
force-pushed
the
better-lifetime-explanation
branch
2 times, most recently
from
7717c4f to
661774b
Compare
src/lifetimes/struct-lifetimes.md
Outdated
| @@ -2,7 +2,7 @@ | |||
| minutes: 5 | |||
| --- | |||
|
|
|||
| # Lifetimes in Data Structures | |||
| # Struct Lifetimes | |||
There was a problem hiding this comment.
Is this the right title? This also works on enums. Maybe something like "Lifetimes in User Defined Types"?
There was a problem hiding this comment.
Actually, during the course I thought that using a struct with a field named document (rather than a newtype) would make the explanations somewhat more natural. What do you think?
There was a problem hiding this comment.
Is this the right title? This also works on enums. Maybe something like "Lifetimes in User Defined Types"?
I'll change it to "Lifetimes in Data Structures" which just barely fits in the sidebar.
Actually, during the course I thought that using a struct with a field named
document(rather than a newtype) would make the explanations somewhat more natural. What do you think?
That's fixed in #2585.
djmitche
force-pushed
the
better-lifetime-explanation
branch
from
c0e57dc to
cc7cfb6
Compare
| Lifetimes are always inferred by the compiler: you cannot assign a lifetime | ||
| yourself. Explicit lifetime annotations create constraints where there is | ||
| ambiguity; the compiler verifies that there is a valid solution. | ||
|
|
||
| Lifetimes become more complicated when considering passing values to and | ||
| returning values from functions. |
There was a problem hiding this comment.
I think this removed text is load-bearing in that it counteracts a common misconception that lifetimes annotations can alter the runtime behavior of programs (in terms of how long values exist and when they are destroyed). We don't need to keep this exact phrasing but in addition to describing lifetimes as constraints we should have some explicit indication that only ownership, not lifetime annotations, control when objects are destroyed and determine the concrete lifetime of a given value.
There was a problem hiding this comment.
Thanks! What do you think of the update?
This approach seems to balance formalism with understanding. That is, it doesn't mention contravariance, but suggests that lifetime annotations in parameters and return values mean "opposite" things. It also leverages the understanding that types must be specified in function signatures, and are used to check types in the function body and at call sites.
djmitche
force-pushed
the
better-lifetime-explanation
branch
from
cc7cfb6 to
96c8e13
Compare
This approach seems to balance formalism with understanding. That is, it doesn't mention contravariance, but suggests that lifetime annotations in parameters and return values mean "opposite" things. It also leverages the understanding that types must be specified in function signatures, and are used to check types in the function body and at call sites.