You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
`T: 'a` means that all lifetime parameters of `T` outlive `'a`.
118
118
For example, if `'a` is an unconstrained lifetime parameter, then `i32: 'static` and `&'static str: 'a` are satisfied, but `Vec<&'a ()>: 'static` is not.
119
119
120
+
In the following text, the words "inferred" and "implied" refer to similar lifetime bounds that may be omitted.
121
+
These different words appear in different contexts in existing documentation, due to implementation details.
122
+
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.
123
+
124
+
For functions and trait implementations, some lifetime bounds are implied because inputs to functions and trait implementations are assumed to be well-formed.
125
+
For the purposes of determining implied bounds on functions, both the function parameter types and the function return type are considered to be inputs.
126
+
127
+
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.
128
+
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`:
129
+
130
+
```rust,compile_fail
131
+
fn f<'a, 'b>(x: &'a i32, mut y: &'b i32) {
132
+
// This is NOT well formed, because the bound `'a: 'b` is missing;
133
+
// therefore, `&'b &'a i32` could possibly outlive `&'a i32`.
134
+
let r: &'b &'a i32 = &&0; // error
135
+
}
136
+
```
137
+
138
+
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.
139
+
Parameters of the trait implementation, which come directly after the `impl` keyword, are not otherwise considered to be inputs.
140
+
For example, for the `Vec<T>` implementation below, `'a` and `Vec<T>` are inputs to the trait, but `T` and `&'a T` are not:
141
+
142
+
```rust
143
+
traitMakeRef<'a> { typeType; }
144
+
145
+
impl<'a, T> MakeRef<'a> forVec<T>
146
+
whereT: 'a// Required because `&'a T` is not an input to the trait
147
+
{
148
+
typeType=&'aT;
149
+
}
150
+
151
+
// `T: 'a` is implied: `&'a T` (implementing type) is an input to the trait
152
+
impl<'a, T> MakeRef<'a> for&'aT {
153
+
typeType=&'aT;
154
+
}
155
+
```
156
+
157
+
For struct definitions, certain lifetime bounds are inferred due to requirements for the types of struct fields to be well-formed.
158
+
These inferred lifetime bounds do not have to be explicitly written on the struct definition.
159
+
160
+
For example, a struct containing a field with a reference such as `&'a T` must satisfy `T: 'a` to be well-formed:
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`.
181
+
An explicit bound is still required to ensure that any lifetime requirements of the associated type are met:
182
+
183
+
```rust
184
+
traitMakeRef<'a> { typeType; }
185
+
186
+
impl<'a, T> MakeRef<'a> forVec<T>
187
+
whereT: 'a
188
+
{
189
+
typeType=&'aT;
190
+
}
191
+
192
+
structUsesMakeRef<'a, T>
193
+
whereT: 'a// Not inferred: only `Vec<T>` is checked to be well-formed
194
+
{
195
+
foo: <Vec<T> asMakeRef<'a>>::Type
196
+
}
197
+
```
198
+
199
+
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`:
0 commit comments