PhantomData

当使用不安全代码时，我们经常会遇到类型或生命周期在逻辑上与结构体相关联，但实际上不是字段一部分的情况。这种情况最常见于生命周期。例如，&'a [T] 的 Iter （近似）定义如下：

#![allow(unused)]
fn main() {
struct Iter<'a, T: 'a> {
    ptr: *const T,
    end: *const T,
}
}

然而，因为 'a 在结构体的主体中没有被使用，它是无界的。 由于历史上由此引起的问题，无界的生命周期和类型在结构体定义中是禁止的。因此，我们必须以某种方式在主体中引用这些类型。正确地这样做对于拥有正确的变性和 drop 检查是必要的。

我们使用 PhantomData 来做到这一点，它是一个特殊的标记类型。 PhantomData 不占用空间，但为了静态分析的目的，它模拟给定类型的字段。这被认为比显式告诉类型系统你想要的变性类型更不容易出错，同时也提供了其他有用的东西，例如自动 traits 和 drop 检查所需的信息。

Iter 逻辑上包含了一堆 &'a T，所以这正是我们告诉 PhantomData 要模拟的内容：

#![allow(unused)]
fn main() {
use std::marker;

struct Iter<'a, T: 'a> {
    ptr: *const T,
    end: *const T,
    _marker: marker::PhantomData<&'a T>,
}
}

就是这样。生命周期将被绑定，并且你的迭代器将对 'a 和 T 是协变的。一切都正常运行。

泛型参数和drop检查

过去，还有另一件事需要考虑。

这篇文档过去常常说：

另一个重要的例子是 Vec，它的（近似）定义如下：

#![allow(unused)]
fn main() {
struct Vec<T> {
    data: *const T, // *const for variance!
    len: usize,
    cap: usize,
}
}

与之前的例子不同，它看起来一切都如我们所愿。Vec 的每个泛型参数都至少出现在一个字段中。一切就绪！

不。

drop 检查器会慷慨地确定 Vec<T> 不拥有任何 T 类型的值。这将反过来使其得出结论，它不需要担心 Vec 在其析构函数中 drop 任何 T，从而确定 drop 检查的健全性。这将反过来允许人们使用 Vec 的析构函数来创建不健全的代码。

为了告诉 drop 检查器我们确实拥有 T 类型的值，因此在我们 drop 时可能会 drop 一些 T，我们必须添加一个额外的 PhantomData 来明确说明：

#![allow(unused)]
fn main() {
use std::marker;

struct Vec<T> {
    data: *const T, // *const for variance!
    len: usize,
    cap: usize,
    _owns_T: marker::PhantomData<T>,
}
}

但是自从 RFC 1238 以来，这不再是正确的，也没有必要。

如果你要写

#![allow(unused)]
fn main() {
struct Vec<T> {
    data: *const T, // `*const` for variance!
    len: usize,
    cap: usize,
}

#[cfg(any())]
impl<T> Drop for Vec<T> { /* … */ }
}

那么 impl<T> Drop for Vec<T> 的存在使得 Rust 会认为 Vec<T> 拥有 T 类型的值（更准确地说：可能会在其 Drop 实现中使用 T 类型的值），因此 Rust 不会允许它们在 Vec<T> 被 drop 时悬空。

当类型已经有 Drop impl 时，添加额外的 _owns_T: PhantomData<T> 字段是多余的，并且在 drop 检查方面没有任何作用（它仍然会影响变性和自动 traits）。

• （高级边缘情况：如果包含 PhantomData 的类型根本没有 Drop impl，但仍然有 drop 胶水（通过拥有另一个带有 drop 胶水的字段），那么这里提到的 drop 检查/#[may_dangle] 考虑也适用：当包含的类型超出范围时，PhantomData<T> 字段将要求 T 可 drop）。

但这种情况有时会导致代码过于严格。这就是为什么标准库使用一个不稳定的和 unsafe 的属性来选择回到旧的“未检查”的 drop 检查行为，而这篇文档警告过：#[may_dangle] 属性。

一个例外：标准库及其不稳定的 #[may_dangle] 的特殊情况

如果你只是编写自己的库代码，可以跳过这一部分；但是如果你对标准库如何使用实际的 Vec 定义感到好奇，你会注意到它仍然需要使用 _owns_T: PhantomData<T> 字段来保证健全性。

fn main() {
    let mut v: Vec<&str> = Vec::new();
    let s: String = "Short-lived".into();
    v.push(&s);
    drop(s);
} // <- `v` is dropped here

unsafe impl<#[may_dangle] 's> Drop for Vec<&'s str> { /* … */ }

unsafe impl<#[may_dangle] T> Drop for Vec<T> { /* … */ }

#![allow(unused)]
fn main() {
#[cfg(any())]
// we pinky-swear not to use `T` when dropping a `Vec`…
unsafe impl<#[may_dangle] T> Drop for Vec<T> {
    fn drop(&mut self) {
        unsafe {
            if mem::needs_drop::<T>() {
                /* … except here, that is, … */
                ptr::drop_in_place::<[T]>(/* … */);
            }
            // …
            dealloc(/* … */)
            // …
        }
    }
}

struct Vec<T> {
    // … except for the fact that a `Vec` owns `T` items and
    // may thus be dropping `T` items on drop!
    _owns_T: core::marker::PhantomData<T>,

    ptr: *const T, // `*const` for variance (but this does not express ownership of a `T` *per se*)
    len: usize,
    cap: usize,
}
}

拥有分配的原始指针是一种如此普遍的模式，以至于标准库为自己创建了一个名为 Unique<T> 的实用程序，它：

• 包装一个 *const T 用于变性
• 包含一个 PhantomData<T>
• 自动派生 Send/Sync，就像包含 T 一样
• 将指针标记为 NonZero，用于空指针优化

PhantomData 模式表

这里是一个关于 PhantomData 所有奇妙使用方式的表格：

• 注意：选择退出 Unpin 自动 trait 需要专用的 PhantomPinned 类型。