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

Обычная безопасная структура Rust не может напрямую хранить ссылку на своё собственное поле, потому что при перемещении структуры её поля могут оказаться по другим адресам. Такая ссылка стала бы указывать на прежнее местоположение данных, поэтому компилятор не позволяет выразить подобную зависимость без специального механизма закрепления объекта.

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

Модель владения Rust должна предотвращать висячие ссылки и use-after-free без сборщика мусора. Для этого компилятор рассматривает перемещение значения как потенциальное изменение его адреса и не предполагает, что внутренние ссылки автоматически последуют за перемещёнными данными.

Это особенно важно для типов, которые можно безопасно передавать по значению. Если бы структура могла свободно содержать ссылку на себя и перемещаться, проверка времени жизни сама по себе не гарантировала бы корректность адреса ссылки.

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

Представим структуру с буфером и ссылкой на часть этого буфера. При создании ссылка должна указывать внутрь объекта, но объект ещё может быть перемещён: например, при возврате из функции, вставке в коллекцию или передаче по значению.

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

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

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

Типичный безопасный вариант — хранить не ссылку, а описание позиции, например диапазон индексов, и создавать краткоживущую ссылку только при обращении:

use std::ops::Range;

struct Document {
    text: String,
    view: Range<usize>,
}

impl Document {
    fn view(&self) -> &str {
        &self.text[self.view.clone()]
    }
}

Здесь структура свободно перемещается, потому что view содержит только числа. Ссылка возникает внутри метода, пока заимствован сам Document, поэтому её время жизни корректно связано с владельцем текста.

Другой путь — использовать Pin и специальную конструкцию самоссылочного типа, часто через проверенные библиотеки. Но одного Pin недостаточно для автоматического создания любой самоссылочной структуры: нужно также корректно гарантировать инициализацию, инварианты адресов и отсутствие перемещения после формирования ссылок.

Внутри Pin обычно применяют указатель на данные, закреплённые в памяти, однако безопасный интерфейс обязан учитывать, какие операции разрешены для конкретного типа. Если тип допускает перемещение своих полей или содержит обычные ссылки с неподходящими временами жизни, закрепление само по себе проблему не решает.

Компромисс очевиден: индексы и повторное заимствование проще, безопаснее и легче перемещаются, но требуют проверки границ и повторного вычисления представления. Закреплённые самоссылочные типы могут избежать этих затрат, однако значительно усложняют проектирование и ограничивают перемещение значения.

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

Парсер хранит исходный текст и часто используемые фрагменты. Разработчик хочет сохранить в объекте ссылки на эти фрагменты, чтобы не выполнять поиск повторно, но объект должен помещаться в растущий вектор результатов.

Вариант с прямыми ссылками на собственное поле не компилируется: вставка объекта в вектор потенциально перемещает его, а внутренние ссылки не могут автоматически обновиться. Вариант с копированием строк устраняет проблему, но увеличивает расход памяти и стоимость создания результатов.

Практичное решение — хранить исходный текст отдельно, например во внешнем владельце, а в объектах результатов держать диапазоны или ссылки с временем жизни внешнего текста. Если объект должен владеть текстом самостоятельно, обычно выбирают диапазоны и получают срезы по запросу.

Такой дизайн сохраняет перемещаемость объектов и делает срок действия представлений явным. Сложность проверки индексов локализуется в одном месте, а риск висячих ссылок исключается средствами типов.

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

1. Достаточно ли объявить структуру с параметром времени жизни, чтобы разрешить ссылку на её собственное поле?

Нет. Параметр времени жизни описывает связь с внешним заимствованием, но не делает структуру самоссылочной. Поле-ссылка с таким параметром обычно заимствует данные у внешнего владельца; оно не может безопасно обозначать зависимость от другого поля того же экземпляра, который ещё может быть перемещён.

2. Решает ли Box проблему самоссылочной структуры?

Само по себе владение через Box не решает её. Перемещение Box обычно меняет место самого указателя, но выделенный объект остаётся по прежнему адресу; однако нужно ещё корректно создать внутреннюю ссылку, связать её время жизни с объектом и гарантировать, что объект больше не будет перемещён из выделенной памяти. Для этого требуется полноценная конструкция с закреплением и соблюдением её инвариантов, а не просто добавление Box.

3. Можно ли заменить внутреннюю ссылку индексом без потери безопасности?

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