@@ -1100,10 +1100,28 @@ mod trait_keyword {}
1100
1100
//
1101
1101
/// A value of type [`bool`] representing logical **true**.
1102
1102
///
1103
- /// The documentation for this keyword is [not yet complete]. Pull requests welcome!
1103
+ /// Logically `true` is not equal to [`false`].
1104
+ ///
1105
+ /// ## Control structures that check for **true**
1106
+ ///
1107
+ /// Several of Rust's control structures will check for a `bool` condition evaluating to **true**.
1108
+ ///
1109
+ /// * The condition in an [`if`] expression must be of type `bool`.
1110
+ /// Whenever that condition evaluates to **true**, the `if` expression takes
1111
+ /// on the value of the first block. If however, the condition evaluates
1112
+ /// to `false`, the expression takes on value of the `else` block if there is one.
1104
1113
///
1114
+ /// * [`while`] is another control flow construct expecting a `bool`-typed condition.
1115
+ /// As long as the condition evaluates to **true**, the `while` loop will continually
1116
+ /// evaluate its associated block.
1117
+ ///
1118
+ /// * [`match`] arms can have guard clauses on them.
1119
+ ///
1120
+ /// [`if`]: keyword.if.html
1121
+ /// [`while`]: keyword.while.html
1122
+ /// [`match`]: ../reference/expressions/match-expr.html#match-guards
1123
+ /// [`false`]: keyword.false.html
1105
1124
/// [`bool`]: primitive.bool.html
1106
- /// [not yet complete]: https://github.com/rust-lang/rust/issues/34601
1107
1125
mod true_keyword { }
1108
1126
1109
1127
#[ doc( keyword = "type" ) ]
@@ -1186,12 +1204,33 @@ mod await_keyword {}
1186
1204
1187
1205
#[ doc( keyword = "dyn" ) ]
1188
1206
//
1189
- /// Name the type of a [trait object].
1207
+ /// `dyn` is a prefix of a [trait object]'s type .
1190
1208
///
1191
- /// The documentation for this keyword is [not yet complete]. Pull requests welcome!
1209
+ /// The `dyn` keyword is used to highlight that calls to methods on the associated `Trait`
1210
+ /// are dynamically dispatched. To use the trait this way, it must be 'object safe'.
1211
+ ///
1212
+ /// Unlike generic parameters or `impl Trait`, the compiler does not know the concrete type that
1213
+ /// is being passed. That is, the type has been [erased].
1214
+ /// As such, a `dyn Trait` reference contains _two_ pointers.
1215
+ /// One pointer goes to the data (e.g., an instance of a struct).
1216
+ /// Another pointer goes to a map of method call names to function pointers
1217
+ /// (known as a virtual method table or vtable).
1218
+ ///
1219
+ /// At run-time, when a method needs to be called on the `dyn Trait`, the vtable is consulted to get
1220
+ /// the function pointer and then that function pointer is called.
1221
+ ///
1222
+ /// ## Trade-offs
1223
+ ///
1224
+ /// The above indirection is the additional runtime cost of calling a function on a `dyn Trait`.
1225
+ /// Methods called by dynamic dispatch generally cannot be inlined by the compiler.
1226
+ ///
1227
+ /// However, `dyn Trait` is likely to produce smaller code than `impl Trait` / generic parameters as
1228
+ /// the method won't be duplicated for each concrete type.
1229
+ ///
1230
+ /// Read more about `object safety` and [trait object]s.
1192
1231
///
1193
1232
/// [trait object]: ../book/ch17-02-trait-objects.html
1194
- /// [not yet complete ]: https://github.com/rust-lang/rust/issues/34601
1233
+ /// [erased ]: https://en.wikipedia.org/wiki/Type_erasure
1195
1234
mod dyn_keyword { }
1196
1235
1197
1236
#[ doc( keyword = "union" ) ]
0 commit comments