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

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

Компилятор проверяет синтаксическую корректность реализации, но не может проверить такие свойства, как отсутствие гонок, корректность владения или сохранение инварианта представления. Поэтому нарушение контракта unsafe trait может привести к неопределённому поведению в коде, который сам не содержит unsafe.

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

В Rust часть гарантий безопасности можно проверить статически: типы ссылок, правила заимствования, владение и многие ограничения потоков. Однако некоторые свойства зависят от семантики реализации и не выражаются обычной системой типов.

unsafe trait нужен для явной фиксации такого контракта. Он позволяет сообщить: реализация этого трейта является не просто функционально корректной, а удовлетворяет дополнительным условиям, от которых зависит безопасность другого кода.

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

Предположим, безопасная функция принимает значение типа T, только если T реализует определённый unsafe trait. Такая функция может не выполнять дополнительных проверок, считая обещания реализации истинными.

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

Особенно опасно, когда реализация выглядит локально безобидной, но её корректность зависит от приватного состояния, времени жизни, синхронизации или всех конструкторов типа.

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

Контракт unsafe trait должен явно описывать, что именно обязан обеспечить реализующий тип. Автор реализации должен проверить это условие для каждого состояния, которое тип может получить через публичный API, включая состояния после перемещения, клонирования, передачи между потоками и вызова методов.

Например, объявление может выглядеть так:

unsafe trait ValidHandle {
    fn is_valid(&self) -> bool;
}

struct Handle(*mut u8);

unsafe impl ValidHandle for Handle {
    fn is_valid(&self) -> bool {
        !self.0.is_null()
    }
}

Сам факт проверки на null не доказывает корректность этой реализации. Если контракт трейта требует, чтобы указатель был действительным для чтения, имел правильное время жизни и принадлежал нужному объекту, приведённая реализация недостаточна: ненулевой указатель может быть висячим.

unsafe impl означает, что автор берёт на себя доказательство соответствия контракту. Внутри реализации можно использовать unsafe, но наличие unsafe-блока не заменяет доказательство инвариантов. Аналогично, отсутствие unsafe в теле не делает реализацию автоматически корректной.

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

Если гарантии зависят от конкретного значения, а не от всех экземпляров типа, чаще подходит обычный безопасный метод с явной проверкой. unsafe trait уместен, когда реализация должна дать универсальное обещание, на которое другие безопасные обобщённые алгоритмы могут полагаться без повторной проверки.

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

Команда создаёт обёртку над дескриптором ресурса ОС. Обобщённый безопасный алгоритм должен работать только с типами, чьи дескрипторы можно безопасно передавать между потоками и закрывать ровно один раз.

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

Второй вариант — проверять корректность дескриптора при каждом вызове. Это может снизить риск, но не гарантирует отсутствие гонок между проверкой и использованием, а также не доказывает уникальность владения. Кроме того, часть инвариантов невозможно надёжно проверить в рантайме.

Выбранный вариант — unsafe trait с явно задокументированным контрактом, приватным созданием обёртки и единственной тщательно проверенной unsafe impl. Публичные методы поддерживают владение и состояние дескриптора, а безопасный алгоритм может полагаться на трейт без дублирования неполных проверок. Результат — небезопасное предположение локализовано в реализации, а не размазано по всем вызовам.

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

Достаточно ли, чтобы все методы реализации сами не содержали unsafe?

Нет. Безопасность определяется не наличием опасных операций в теле, а соблюдением контракта трейта. Реализация может состоять только из безопасного кода и всё равно быть неверной, если она обещает свойство, которого тип фактически не имеет.

Например, безопасный метод может вернуть true для ненулевого, но уже освобождённого указателя. Компилятор не обязан проверять смысл такого обещания.

Может ли проверка инварианта внутри каждого метода заменить unsafe trait?

Иногда да, если проверка полная, атомарная относительно использования и доступна во всех путях. Но часто она только обнаруживает часть проблем: проверка ненулевого адреса не подтверждает действительность памяти, а проверка флага состояния не устраняет гонку без синхронизации.

unsafe trait фиксирует более сильное обещание на уровне типа или реализации. Если оно действительно зависит от каждого вызова и может быть надёжно проверено, безопасный метод с результатом Option или Result обычно понятнее и безопаснее.

Что происходит с unsafe impl, если внутреннее устройство типа позже изменилось?

Реализацию нужно пересмотреть так же тщательно, как небезопасный код. Добавление поля, изменение владения ресурсом, нового способа клонирования или другой синхронизации может нарушить исходный инвариант, даже если сигнатуры трейта не изменились.

Поэтому контракт unsafe trait является частью ответственности автора типа. Документация, приватные конструкторы, тесты конкурентных сценариев и изолированный участок unsafe снижают риск, но окончательная гарантия всё равно требует ручного анализа.