Краткий ответ

Чтобы тип был Copy, все его поля должны быть Copy. Для обобщённой структуры это обычно означает ограничение параметров типа: при автоматическом выводе через derive Rust добавляет требования T: Copy для соответствующих параметров.

Кроме того, Copy требует реализации Clone и несовместим с Drop. Копирование такого значения происходит неявно и не делает исходное имя недоступным.

Исторический контекст

Copy появился как способ выразить семантику небольших значений, безопасное побитовое дублирование которых не требует отдельного управления ресурсами. Это позволяет передавать числа, логические значения и другие простые дескрипторы без перемещения владения.

Подход отделяет типы-значения от типов, владеющих ресурсами. Для String, файловых дескрипторов или других владельцев автоматическое неявное копирование могло бы привести к двойному освобождению или неоднозначному владению, поэтому такие типы не могут быть Copy.

Постановка проблемы

Рассмотрим обобщённую структуру, содержащую числовой идентификатор и маркер типа. На уровне представления ей может быть достаточно одного числа, однако автоматический derive(Copy) способен потребовать Copy от параметра типа, даже если параметр фактически не хранится в данных.

Неверное понимание этого правила приводит к ошибкам компиляции при использовании, например, String как параметра-маркера. С другой стороны, ручная реализация Copy без проверки полей невозможна: компилятор не позволит объявить Copy для типа, который может содержать не копируемый ресурс.

Подробное решение

Для структуры struct Pair<T> { value: T } тип Pair<T> является Copy только тогда, когда T: Copy. Поле value копируется вместе со всей структурой, поэтому без этого ограничения безопасная реализация Copy невозможна.

При использовании #[derive(Copy, Clone)] Rust генерирует реализации с необходимыми ограничениями. Важная деталь: производный код может добавить ограничение на параметр типа даже тогда, когда параметр используется только в PhantomData<T> и не влияет на фактическое хранение значения.

use std::marker::PhantomData;

#[derive(Copy, Clone)]
struct Derived<T> {
    raw: u64,
    marker: PhantomData<T>,
}

struct Manual<T> {
    raw: u64,
    marker: PhantomData<T>,
}

impl<T> Copy for Manual<T> {}
impl<T> Clone for Manual<T> {
    fn clone(&self) -> Self { *self }
}

fn main() {
    let id = Manual::<String> { raw: 7, marker: PhantomData };
    let copy = id;
    println!("{} {}", id.raw, copy.raw);
}

В примере Manual<String> можно копировать, потому что String не хранится в значении: PhantomData<T> занимает нулевой размер и лишь сообщает компилятору о логической связи с T. Ручная реализация здесь корректна, но требует от разработчика доказать, что все фактические поля действительно копируемы.

Copy является маркерным трейтом и наследуется от Clone: тип, реализующий Copy, должен также иметь Clone. При присваивании, передаче аргумента или возврате Copy-значения Rust копирует его, поэтому исходное выражение остаётся доступным.

Тип с Drop не может реализовать Copy. Иначе неявная копия создавала бы несколько значений, каждое из которых считалось бы ответственным за один и тот же ресурс.

Ситуация из практики

В библиотеке вводится типизированный идентификатор с числовым представлением и параметром-маркером: например, идентификатор пользователя и идентификатор заказа. Разработчик применяет derive(Copy, Clone) и обнаруживает, что идентификатор с маркером String не проходит ограничение Copy, хотя строка внутри структуры отсутствует.

Первый вариант — оставить derive. Его плюс в простоте и автоматической проверке всех полей, но он может навязать избыточное требование T: Copy из-за обобщённого параметра. Второй вариант — сделать параметр маркером и реализовать Copy и Clone вручную; это устраняет лишнее ограничение, но требует аккуратно поддерживать инварианты при изменении структуры.

Практический выбор — ручная реализация только для прозрачного типа, чьи реальные поля заведомо копируемы, например u64 и PhantomData<T>. Результатом становится компактный типизированный идентификатор, который можно передавать по значению без перемещения и при этом использовать с неCopy маркерами.

Что кандидаты часто упускают

Достаточно ли указать только Copy, не реализуя Clone?

Нет. Copy требует Clone, поэтому компилятор отклонит реализацию, если для типа отсутствует совместимая реализация Clone. Обычно применяют #[derive(Copy, Clone)], а при ручной реализации определяют оба трейта.
Можно ли реализовать Copy для структуры с полем String, если копирование нужно только иногда?

Нет. Реализация трейта относится ко всему типу, а не к отдельным операциям. Поскольку String владеет буфером и не является Copy, структура с таким полем тоже не может быть Copy; для явного дублирования нужно использовать Clone, который может выполнять глубокое копирование.
Всегда ли derive(Copy) требует Copy от параметра, упомянутого только в PhantomData<T>?

Для производной реализации такое ограничение обычно добавляется по параметру, поэтому Derived<String> из примера не сможет использоваться как Copy, несмотря на нулевой размер PhantomData<T>. Если фактическое представление не содержит T, разработчик может вручную реализовать Copy и Clone с более точными ограничениями, но обязан убедиться, что изменение полей в будущем не нарушит безопасность такой реализации.