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));
RunFor 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:
Copy
Clone
(Note that this will not defer toT
’sClone
implementation if it exists!)Deref
Borrow
fmt::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::fmt
exceptfmt::Pointer
(which is implemented regardless of the type of its referent) andfmt::Write
PartialOrd
Ord
PartialEq
Eq
AsRef
Fn
(in addition,&T
references getFnMut
andFnOnce
ifT: Fn
)Hash
ToSocketAddrs
Sync
&mut T
references get all of the above except ToSocketAddrs
, plus the following, if T
implements that trait:
AsMut
FnMut
(in addition,&mut T
references getFnOnce
ifT: FnMut
)fmt::Write
Iterator
DoubleEndedIterator
ExactSizeIterator
FusedIterator
TrustedLen
Send
io::Write
Read
Seek
BufRead
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:
t
is aligned toalign_of_val(t)
t
is 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.