Skip to content

Commit 686b13f

Browse files
tlyutraviscross
authored andcommitted
document implicit lifetime bounds
Add documentation about implicit lifetime bounds that the compiler can infer for functions, trait implementations, and structs. This draws from RFC 2093 (for structs) and RFC 1214 for functions and trait implementations.
1 parent 458882b commit 686b13f

File tree

1 file changed

+87
-0
lines changed

1 file changed

+87
-0
lines changed

src/trait-bounds.md

+87
Original file line numberDiff line numberDiff line change
@@ -146,6 +146,93 @@ r[bound.lifetime.outlive-type]
146146
`T: 'a` means that all lifetime parameters of `T` outlive `'a`.
147147
For example, if `'a` is an unconstrained lifetime parameter, then `i32: 'static` and `&'static str: 'a` are satisfied, but `Vec<&'a ()>: 'static` is not.
148148

149+
In the following text, the words "inferred" and "implied" refer to similar lifetime bounds that may be omitted.
150+
These different words appear in different contexts in existing documentation, due to implementation details.
151+
From the programmer's perspective, they both refer to a category of lifetime bounds that are not required to be explicitly written because the compiler can derive them from other information.
152+
153+
For functions and trait implementations, some lifetime bounds are implied because inputs to functions and trait implementations are assumed to be well-formed.
154+
For the purposes of determining implied bounds on functions, both the function parameter types and the function return type are considered to be inputs.
155+
156+
For example, for a function parameter `x: &'a T` to be well-formed, `T: 'a` must be satisfied (referents must outlive any references to them), so it is not necessary to explicitly write that lifetime bound on the function definition.
157+
On the other hand, removing the bound `where 'a: 'b` from the above example results in an error, because the constructed reference type exists only in the function body and is not among the inputs to `f`:
158+
159+
```rust,compile_fail
160+
fn f<'a, 'b>(x: &'a i32, mut y: &'b i32) {
161+
// This is NOT well formed, because the bound `'a: 'b` is missing;
162+
// therefore, `&'b &'a i32` could possibly outlive `&'a i32`.
163+
let r: &'b &'a i32 = &&0; // error
164+
}
165+
```
166+
167+
For the purpose of determining implied bounds on trait implementations, the implementing type (the `T` in `impl Trait for T`) is considered to be an input, as are generic parameters on the trait definition.
168+
Parameters of the trait implementation, which come directly after the `impl` keyword, are not otherwise considered to be inputs.
169+
For example, for the `Vec<T>` implementation below, `'a` and `Vec<T>` are inputs to the trait, but `T` and `&'a T` are not:
170+
171+
```rust
172+
trait MakeRef<'a> { type Type; }
173+
174+
impl<'a, T> MakeRef<'a> for Vec<T>
175+
where T: 'a // Required because `&'a T` is not an input to the trait
176+
{
177+
type Type = &'a T;
178+
}
179+
180+
// `T: 'a` is implied: `&'a T` (implementing type) is an input to the trait
181+
impl<'a, T> MakeRef<'a> for &'a T {
182+
type Type = &'a T;
183+
}
184+
```
185+
186+
For struct definitions, certain lifetime bounds are inferred due to requirements for the types of struct fields to be well-formed.
187+
These inferred lifetime bounds do not have to be explicitly written on the struct definition.
188+
189+
For example, a struct containing a field with a reference such as `&'a T` must satisfy `T: 'a` to be well-formed:
190+
191+
```rust
192+
struct RefToSlice1<'a, T>(&'a [T]); // inferred
193+
struct RefToSlice2<'a, T>(&'a [T]) where T: 'a; // explicit
194+
// References to references have additional requirements that can be inferred.
195+
struct DoubleRef1<'a, 'b, T>(&'a &'b T); // inferred
196+
struct DoubleRef2<'a, 'b, T>(&'a &'b T) where 'b: 'a, T: 'b; // explicit
197+
```
198+
199+
A reference to a struct such as `Bar<'a, T>` can also result in inferred lifetime bounds derived from the definition of `Bar`.
200+
The explicit `T: 'a` bound in the `where` clause on `Bar` causes the bound `U: 'b` to be inferred on `Foo1`:
201+
202+
```rust
203+
struct Foo1<'b, U>(Bar<'b, U>); // inferred
204+
struct Foo2<'b, U>(Bar<'b, U>) where U: 'b; // explicit
205+
206+
struct Bar<'a, T>(&'a (), T) where T: 'a;
207+
```
208+
209+
For associated type references such as `<T as MakeRef<'a>>::Type`, only `T` itself is checked to be well-formed, and no lifetime bounds are inferred based on the lifetime requirements of the associated type `MakeRef<'a>::Type`.
210+
An explicit bound is still required to ensure that any lifetime requirements of the associated type are met:
211+
212+
```rust
213+
trait MakeRef<'a> { type Type; }
214+
215+
impl<'a, T> MakeRef<'a> for Vec<T>
216+
where T: 'a
217+
{
218+
type Type = &'a T;
219+
}
220+
221+
struct UsesMakeRef<'a, T>
222+
where T: 'a // Not inferred: only `Vec<T>` is checked to be well-formed
223+
{
224+
foo: <Vec<T> as MakeRef<'a>>::Type
225+
}
226+
```
227+
228+
In contrast, `<T as Iterator>::Item: 'a` is inferred below, because `'a` is part of the type of the reference, not part of the associated type `<T as Iterator>::Item`:
229+
230+
```rust
231+
struct RefAssocType1<'a, T: Iterator>(&'a T::Item); // inferred
232+
struct RefAssocType2<'a, T: Iterator>(&'a T::Item)
233+
where <T as Iterator>::Item: 'a; // explicit
234+
```
235+
149236
## Higher-ranked trait bounds
150237

151238
r[bound.higher-ranked]

0 commit comments

Comments
 (0)