Команда Rust показала прототип «Beyond the &»: умные указатели как ссылки
На конференции RustConf 2026 Тайлер Мэндри (Tyler Mandry), руководитель языковой команды проекта Rust, рассказал о долгой работе, цель которой, сделать пользовательские умные указатели такими же гибкими, как встроенные ссылки. Проект называется «Beyond the &». Мэндри говорит, что занимается им весь 2026 год вместе с несколькими другими участниками языковой команды. Об этом докладе рассказывает LWN.
Проблему Мэндри показал на примере. Простая программа считает динамическое содержимое и кеширует его в хеш-таблице через API записей (entry) и функцию or_insert_with(), которой передаётся замыкание для заполнения пустой записи. Состояние передаётся как встроенная изменяемая ссылка &mut RenderState, и код компилируется: анализатор заимствований (borrow checker) видит, что поля state.cache и state.template, разные и их можно использовать одновременно. Стоит обернуть состояние в мьютекс, чтобы делить его между потоками, как анализатор отвергает программу: он видит лишь непрозрачные обращения к структуре MutexGuard и уже не может понять, что доступ к полям не пересекается. Обходной путь, один раз разыменовать MutexGuard и заново позаимствовать структуру: let state: &mut RenderState = &mut *state.lock().unwrap(). Это работает, но неинтуитивно; по словам Мэндри, такая сложность добавляет крутизны кривой обучения Rust. Указателей в языке много, и у каждого свои особенности: сырые указатели нельзя безопасно разыменовывать, в MaybeUninit можно писать, но нельзя читать. Поэтому общий дизайн придумать трудно.
Решение команда построила на работах Nadrieril и Бенно Лоссина (Benno Lossin): открыть коду пользователя внутреннее понятие компилятора, «место» (place). Место, это аналог lvalue в C: расположение, из которого можно читать и в которое можно писать. Место, абстрактное выражение времени компиляции (например, state.cache), а указатель, один из способов представить место во время выполнения. Идея в том, чтобы завести для каждого умного указателя новый тип-дескриптор (handle), часто это просто обёртка над небезопасным указателем на то же место. Компилятор сам создаёт дескрипторы для мест, на которые ссылается программа, а пользовательский код реализует для этих типов трейты, определяющие взаимодействие с анализатором заимствований. Это даёт больше свободы, чем существующие трейты Deref и DerefMut.
Трейт WritePlace сообщает анализатору, что в место можно писать и как. Мэндри показал пример для указателя NonNull: когда константа SAFE равна false, запись считается небезопасной операцией, а реализация самого трейта помечена unsafe, поскольку ошибка в ней может привести к неверному решению анализатора и некорректному поведению. ReadPlace описывает чтение. ProjectPlace объясняет, как превратить место со структурой в место с одним из её полей, например, MutexGuard
Есть и другие выгоды. Сегодня сопоставление с образцом работает со значением за ссылкой, но не за умным указателем (без разыменования и повторного заимствования). Сведений из BorrowPlace хватит, чтобы компилятор мог безопасно поддержать такое сопоставление. Среди критериев языковой команды Мэндри назвал композируемость: насколько новая возможность вписывается в язык и сочетается с другими. Дескрипторы и места, по его словам, «прекрасно сочетаются», потому что лишь открывают то, как компилятор и так понимает язык.
Тем не менее открытие мест и дескрипторов библиотечному коду пока остаётся прототипом. Мэндри попросил слушателей изучить документацию дизайна, добавить свои примеры умных указателей с необычной семантикой и сообщать о препятствиях. Следующий шаг, ошибки и диагностические сообщения: в идеале пользователи не должны видеть ошибок с упоминанием новых трейтов, сообщения должны объяснять проблему напрямую, как для встроенных ссылок. До стабильной части языка ещё много работы, но Мэндри настроен оптимистично.
На вопросах из зала Мэндри ответил, что деструктивное сопоставление с образцом (с получением владения значением) будет поддержано, если разработчик реализует для дескриптора трейт VariantPlace; всего для поддержки всех операций над типом-дескриптором нужно реализовать от шести до восьми операций. На вопрос, подойдёт ли дизайн для перечислений (enum) в общем случае, он после паузы протяжно согласился, но уточнил: проецировать поле из перечисления в общем случае, вероятно, не получится, хотя пробные наработки есть. Можно ли, например, получить из Option поле и вернуть Option от значения поля, он не знает: «Я не знаю ответа, но это интересный вопрос». Время сессии на этом вышло.
Ключевые факты
- Проект «Beyond the &» языковой команды Rust направлен на то, чтобы пользовательские умные указатели (например, MutexGuard) вели себя как встроенные ссылки; Тайлер Мэндри работает над ним весь 2026 год.
- Идея: открыть коду пользователя внутреннее понятие компилятора «место» (place) и завести для каждого умного указателя тип-дескриптор (handle) с трейтами WritePlace, ReadPlace, ProjectPlace и BorrowPlace; это гибче, чем Deref и DerefMut.
- Пример с кешем в хеш-таблице: после добавления мьютекса borrow checker отвергает код, а с дескриптором для MutexGuard исходный render_page() компилируется без обходного разыменования.
- Синтаксис создания нового умного указателя через BorrowPlace не решён: символ & может запутать, @ предлагают, но не все им довольны.
- Это пока прототип: следующий этап, ошибки и диагностика; для всех операций над дескриптором нужно реализовать от шести до восьми операций, а проекция поля из enum в общем случае, вероятно, невозможна.
Почему это важно
Умные указатели есть и в стандартной библиотеке Rust, и в пользовательских библиотеках, но часть операций доступна только встроенным ссылкам. Из-за этого код с MutexGuard приходится переписывать обходными разыменованиями вроде &mut *state.lock().unwrap(), а Мэндри связывает такую неинтуитивность с трудной кривой обучения языка. Дизайн языковой команды, по её мнению, должен дать заметно более простую ментальную модель указателей и ссылок и позволить библиотекам расширять язык, не прибегая к особым правам компилятора.
Кому это важно
Прежде всего авторам библиотек на Rust, которые пишут собственные умные указатели и обёртки с необычной семантикой, и разработчикам языка и компилятора. Мэндри прямо просит их проверить дизайн на своих случаях. Рядовым пользователям Rust, которые работают с Mutex и подобными типами, дизайн в перспективе обещает меньше обходных приёмов.
Как это применить
Пока применять нечего: это прототип, а до стабильной части языка, по словам Мэндри, ещё много работы. Срока, номера версии или даты стабилизации в материале нет. Практический шаг, о котором просил докладчик, изучить документацию дизайна, добавить свои примеры умных указателей с необычной семантикой и сообщить о препятствиях, если есть абстракция, которую хочется глубже встроить в язык.
Можно ли доверять
Материал, отчёт LWN о докладе Мэндри на RustConf 2026, поэтому описание дизайна, примеры кода и оценки («небольшое изменение, но большой семантический сдвиг») передаются в пересказе издания, а прямые слова докладчика приведены в кавычках. Сам дизайн ещё не окончательный: синтаксис не выбран, измерений производительности и времени компиляции в тексте нет. Оптимизм Мэндри, его личная оценка, а не гарантия результата.
Риски и подводные камни
Дизайн остаётся прототипом, и детали могут измениться, в том числе синтаксис заимствования (& или @, вопрос открыт). Реализации трейтов небезопасны (unsafe): ошибка в них может привести к неверному решению анализатора заимствований и некорректному поведению. Не всё покрывается: проекция поля из enum в общем случае, вероятно, невозможна, а вопрос о проекции поля из Option остаётся открытым. Ещё предстоит сделать так, чтобы пользователи не сталкивались с ошибками, где упоминаются новые трейты. Заменят ли новые трейты Deref и DerefMut, в материале не сказано, только то, что они гибче.
«Моя надежда в том, что это позволит библиотекам сделать Rust ещё более мощным и дружелюбным.»
— Тайлер Мэндри, руководитель языковой команды Rust, RustConf 2026