PhantomData

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

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

然而，由于 `'a` 未在结构体的正文中使用，因此它是*无界*的。由于这在历史上造成的问题，无界生命周期和类型在结构体定义中是被*禁止*的。因此，我们必须以某种方式在正文中引用这些类型。正确地做到这一点对于拥有正确的变型和 Drop 检查至关重要。

我们使用 `PhantomData` 来做到这一点，它是一种特殊的标记类型。`PhantomData` 不占用空间，但为了静态分析的目的，它模拟了给定类型的字段。这被认为比明确告诉类型系统你想要的变型类型更不容易出错，同时也提供了其他有用的东西，比如自动 trait 和 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 在其析构函数中丢弃任何 T 来确定 Drop 检查的健全性。这反过来又会允许人们使用 Vec 的析构函数来创建不健全的行为。

为了告诉 Drop 检查器我们*确实*拥有 T 类型的，因此当*我们*丢弃时可能会丢弃一些 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 类型的），因此如果 `Vec<T>` 被丢弃，Rust 将不允许它们*悬空*。

当一个类型已经有一个 `Drop impl` 时，添加一个额外的 `_owns_T: PhantomData<T>` 字段是*多余的*，没有任何意义，就 Drop 检查而言（它仍然会影响变型和自动 trait）。

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

但这种情况有时会导致代码过于严格。这就是为什么标准库使用一个不稳定的 `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 自动特征需要专用的 PhantomPinned 类型。