All items of this type can be compared and ordered.

Some items of this type can be compared and ordered.

There's a partial equivalence relation for items of this type—any two items can be definitively compared, but it may not always be true that x==x.

There's an equivalence relation for items of this type—any two items can be definitively compared, and it is always true that x==x.

Expressing loops as iterator transformations can also produce code that is more efficient. In the interests of safety, Rust performs bounds checking on access to contiguous containers such as vectors and slices; an attempt to access a value beyond the bounds of the collection triggers a panic rather than an access to invalid data. An old-style loop that accesses container values (e.g., values[i]) might be subject to these runtime checks, whereas an iterator that produces one value after another is already known to be within range.

This rich collection of iterator transformations is there to be used. It produces code that is more idiomatic, more compact, and has clearer intent.

Builds an accumulated value of an arbitrary type by running a closure at each step that takes a mutable reference to some internal state and the current item. This is a slightly different generalization of reduce.

Builds an accumulated value of an arbitrary type (not just the Iterator::Item type) by running a closure at each step that takes the value accumulated so far and the current item. This is a generalization of reduce.

iterator transforms can be more efficient than an explicit loop, because the compiler can skip the bounds checks it might otherwise need to perform.

allowing the whole loop to be expressed as an iterator transform (sometimes also referred to as an iterator adaptor).

If the underlying type T implements the Copy trait (indicating that a fast bit-for-bit copy produces a valid item; see Item 10), then the Cell<T> type allows interior mutation with less overhead—the get(&self) method copies out the current value, and the set(&self, val) method copies in a new value. The Cell type is used internally by both the Rc and RefCell implementations, for shared tracking of counters that can be mutated without a &mut self.

The underlying item is dropped when the strong reference count drops to zero, but the bookkeeping structure is dropped only when the weak reference count also drops to zero.

If they were, then it would be possible for some type ConfusedPtr to implement both Deref<TypeA> and Deref<TypeB>, and that would leave the compiler unable to deduce a single unique type for an expression like *x

error[E0716]: temporary value dropped while borrowed --> src/main.rs:265:19 | 265 | let builder = DetailsBuilder::new( | ___________________^ 266 | | "Robert", 267 | | "Builder", 268 | | time::Date::from_calendar_date(1998, time::Month::November, 28) 269 | | .unwrap(), 270 | | ) | |_____^ creates a temporary value which is freed while still in use 271 | .middle_name("the") 272 | .just_seen(); | - temporary value is freed at the end of this statement 273 | let bob = builder.build(); | --------------- borrow later used here | = note: consider using a `let` binding to create a longer lived value

if informal { builder.preferred_name("Bob"); }

This boilerplate code is also brittle, in the sense that a future change that adds a new field to the struct requires an update to every place that builds the structure.

Rust insists that all fields in a struct must be filled in when a new instance of that struct is created. This keeps the code safe by ensuring that there are never any uninitialized values but does lead to more verbose boilerplate code than is ideal.