Skip to content

Commit d7bf3d3

Browse files
committed
Rollup merge of rust-lang#32431 - nicholasf:tweak/improve-expression, r=steveklabnik
Simplifying some of the phrasing explaining lifetime elision Just simplifying some of the language expressing what kind of inference Rust can and can't do on function signatures.
2 parents 12e54bb + 45c72d5 commit d7bf3d3

File tree

1 file changed

+6
-8
lines changed

1 file changed

+6
-8
lines changed

src/doc/book/lifetimes.md

+6-8
Original file line numberDiff line numberDiff line change
@@ -282,14 +282,12 @@ to it.
282282

283283
## Lifetime Elision
284284

285-
Rust supports powerful local type inference in function bodies, but it’s
286-
forbidden in item signatures to allow reasoning about the types based on
287-
the item signature alone. However, for ergonomic reasons a very restricted
288-
secondary inference algorithm called “lifetime elision” applies in function
289-
signatures. It infers only based on the signature components themselves and not
290-
based on the body of the function, only infers lifetime parameters, and does
291-
this with only three easily memorizable and unambiguous rules. This makes
292-
lifetime elision a shorthand for writing an item signature, while not hiding
285+
Rust supports powerful local type inference in the bodies of functions but not in their item signatures.
286+
It's forbidden to allow reasoning about types based on the item signature alone.
287+
However, for ergonomic reasons, a very restricted secondary inference algorithm called
288+
“lifetime elision” does apply when judging lifetimes. Lifetime elision is concerned solely to infer
289+
lifetime parameters using three easily memorizable and unambiguous rules. This means lifetime elision
290+
acts as a shorthand for writing an item signature, while not hiding
293291
away the actual types involved as full local inference would if applied to it.
294292

295293
When talking about lifetime elision, we use the term *input lifetime* and

0 commit comments

Comments
 (0)