Primitive Type reference
1.0.0 ·Expand description
References, &T and &mut T.
A reference represents a borrow of some owned value. You can get one by using the & or &mut
operators on a value, or by using a ref or
ref mut pattern.
For those familiar with pointers, a reference is just a pointer that is assumed to be
aligned, not null, and pointing to memory containing a valid value of T - for example,
&bool can only point to an allocation containing the integer values 1
(true) or 0 (false), but
creating a &bool that points to an allocation containing
the value 3 causes undefined behaviour.
In fact, Option<&T> has the same memory representation as a
nullable but aligned pointer, and can be passed across FFI boundaries as such.
In most cases, references can be used much like the original value. Field access, method calling, and indexing work the same (save for mutability rules, of course). In addition, the comparison operators transparently defer to the referent’s implementation, allowing references to be compared the same as owned values.
References have a lifetime attached to them, which represents the scope for which the borrow is
valid. A lifetime is said to “outlive” another one if its representative scope is as long or
longer than the other. The 'static lifetime is the longest lifetime, which represents the
total life of the program. For example, string literals have a 'static lifetime because the
text data is embedded into the binary of the program, rather than in an allocation that needs
to be dynamically managed.
&mut T references can be freely coerced into &T references with the same referent type, and
references with longer lifetimes can be freely coerced into references with shorter ones.
Reference equality by address, instead of comparing the values pointed to, is accomplished via
implicit reference-pointer coercion and raw pointer equality via ptr::eq, while
PartialEq compares values.
use std::ptr;
let five = 5;
let other_five = 5;
let five_ref = &five;
let same_five_ref = &five;
let other_five_ref = &other_five;
assert!(five_ref == same_five_ref);
assert!(five_ref == other_five_ref);
assert!(ptr::eq(five_ref, same_five_ref));
assert!(!ptr::eq(five_ref, other_five_ref));For more information on how to use references, see the book’s section on “References and Borrowing”.
§Trait implementations
The following traits are implemented for all &T, regardless of the type of its referent:
CopyClone(Note that this will not defer toT’sCloneimplementation if it exists!)DerefBorrowfmt::Pointer
&mut T references get all of the above except Copy and Clone (to prevent creating
multiple simultaneous mutable borrows), plus the following, regardless of the type of its
referent:
The following traits are implemented on &T references if the underlying T also implements
that trait:
- All the traits in
std::fmtexceptfmt::Pointer(which is implemented regardless of the type of its referent) andfmt::Write PartialOrdOrdPartialEqEqAsRefFn(in addition,&Treferences getFnMutandFnOnceifT: Fn)HashToSocketAddrsSync
&mut T references get all of the above except ToSocketAddrs, plus the following, if T
implements that trait:
AsMutFnMut(in addition,&mut Treferences getFnOnceifT: FnMut)fmt::WriteIteratorDoubleEndedIteratorExactSizeIteratorFusedIteratorTrustedLenSendio::WriteReadSeekBufRead
In addition, &T references implement Send if and only if T implements Sync.
Note that due to method call deref coercion, simply calling a trait method will act like they
work on references as well as they do on owned values! The implementations described here are
meant for generic contexts, where the final type T is a type parameter or otherwise not
locally known.
§Safety
For all types, T: ?Sized, and for all t: &T or t: &mut T, when such values cross an API
boundary, the following invariants must generally be upheld:
tis aligned toalign_of_val(t)tis dereferenceable forsize_of_val(t)many bytes
If t points at address a, being “dereferenceable” for N bytes means that the memory range
[a, a + N) is all contained within a single allocated object.
For instance, this means that unsafe code in a safe function may assume these invariants are ensured of arguments passed by the caller, and it may assume that these invariants are ensured of return values from any safe functions it calls. In most cases, the inverse is also true: unsafe code must not violate these invariants when passing arguments to safe functions or returning values from safe functions; such violations may result in undefined behavior. Where exceptions to this latter requirement exist, they will be called out explicitly in documentation.
It is not decided yet whether unsafe code may violate these invariants temporarily on internal data. As a consequence, unsafe code which violates these invariants temporarily on internal data may become unsound in future versions of Rust depending on how this question is decided.