Struct core::marker::PhantomData
1.0.0 · source · [−]pub struct PhantomData<T: ?Sized>;Expand description
Zero-sized type used to mark things that “act like” they own a T.
Adding a PhantomData<T> field to your type tells the compiler that your
type acts as though it stores a value of type T, even though it doesn’t
really. This information is used when computing certain safety properties.
For a more in-depth explanation of how to use PhantomData<T>, please see
the Nomicon.
A ghastly note 👻👻👻
Though they both have scary names, PhantomData and ‘phantom types’ are
related, but not identical. A phantom type parameter is simply a type
parameter which is never used. In Rust, this often causes the compiler to
complain, and the solution is to add a “dummy” use by way of PhantomData.
Examples
Unused lifetime parameters
Perhaps the most common use case for PhantomData is a struct that has an
unused lifetime parameter, typically as part of some unsafe code. For
example, here is a struct Slice that has two pointers of type *const T,
presumably pointing into an array somewhere:
The intention is that the underlying data is only valid for the
lifetime 'a, so Slice should not outlive 'a. However, this
intent is not expressed in the code, since there are no uses of
the lifetime 'a and hence it is not clear what data it applies
to. We can correct this by telling the compiler to act as if the
Slice struct contained a reference &'a T:
use std::marker::PhantomData;
struct Slice<'a, T: 'a> {
start: *const T,
end: *const T,
phantom: PhantomData<&'a T>,
}This also in turn requires the annotation T: 'a, indicating
that any references in T are valid over the lifetime 'a.
When initializing a Slice you simply provide the value
PhantomData for the field phantom:
fn borrow_vec<T>(vec: &Vec<T>) -> Slice<'_, T> {
let ptr = vec.as_ptr();
Slice {
start: ptr,
end: unsafe { ptr.add(vec.len()) },
phantom: PhantomData,
}
}Unused type parameters
It sometimes happens that you have unused type parameters which
indicate what type of data a struct is “tied” to, even though that
data is not actually found in the struct itself. Here is an
example where this arises with FFI. The foreign interface uses
handles of type *mut () to refer to Rust values of different
types. We track the Rust type using a phantom type parameter on
the struct ExternalResource which wraps a handle.
use std::marker::PhantomData;
use std::mem;
struct ExternalResource<R> {
resource_handle: *mut (),
resource_type: PhantomData<R>,
}
impl<R: ResType> ExternalResource<R> {
fn new() -> Self {
let size_of_res = mem::size_of::<R>();
Self {
resource_handle: foreign_lib::new(size_of_res),
resource_type: PhantomData,
}
}
fn do_stuff(&self, param: ParamType) {
let foreign_params = convert_params(param);
foreign_lib::do_stuff(self.resource_handle, foreign_params);
}
}Ownership and the drop check
Adding a field of type PhantomData<T> indicates that your
type owns data of type T. This in turn implies that when your
type is dropped, it may drop one or more instances of the type
T. This has bearing on the Rust compiler’s drop check
analysis.
If your struct does not in fact own the data of type T, it is
better to use a reference type, like PhantomData<&'a T>
(ideally) or PhantomData<*const T> (if no lifetime applies), so
as not to indicate ownership.