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

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

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

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

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

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

Обычному перечислению нужно различать варианты, например успешный результат и ошибку. Наивное представление содержит payload и отдельный дискриминант, что может увеличивать размер структуры из-за самого дискриминанта или выравнивания.

Однако некоторые типы уже имеют свободные битовые шаблоны. Ссылка в Rust не может быть нулевой, а типы NonZero* не допускают нулевое значение. Если Result содержит такой тип, компилятор может использовать недопустимое значение как признак другого варианта.

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

Внутренне Result<T, E> логически имеет два варианта: Ok(T) и Err(E). При обычном представлении компилятор хранит значение варианта отдельно от его payload, но при наличии ниши может встроить дискриминант в свободное значение payload.

Например, корректная ссылка всегда ненулевая. Для Result<&T, ()> нулевое значение может представлять Err(()), а ненулевые значения — Ok(&T). В таком случае результат может занимать столько же памяти, сколько ссылка, хотя точная раскладка зависит от типа и реализации компилятора.

use std::mem::size_of;

fn main() {
    println!("{}", size_of::<&u8>());
    println!("{}", size_of::<Result<&u8, ()>>());
    println!("{}", size_of::<Result<u64, u8>>());
}

Этот пример позволяет исследовать размер типов, но конкретные числа нельзя превращать в переносимый контракт без соответствующей гарантии документации. Нельзя безопасно полагаться на такую раскладку через transmute, ручную сериализацию или FFI.

Наличие ниши не гарантирует минимальный размер для любого Result. Если ни один компонент не предоставляет подходящего недопустимого значения, компилятору потребуется отдельный дискриминант либо другое представление. #[repr(C)] и требования внешнего ABI также меняют вопрос: для взаимодействия с C нужно явно проектировать совместимое представление, а не рассчитывать на внутреннюю оптимизацию Rust.

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

Библиотека возвращает найденную запись по ссылке либо сообщает, что записи нет. Возможны три решения: использовать отдельную пару из флага и ссылки, вернуть специальный нулевой указатель или применить Result<&Record, ()>.

Пара из флага и ссылки проста для ручного контроля, но может занимать больше памяти и допускает несогласованные состояния. Нулевой указатель эффективен на уровне ABI, но небезопасен и хуже выражает контракт в типах. Result<&Record, ()> явно описывает два исхода, позволяет компилятору потенциально использовать нишу ссылки и сохраняет безопасную проверку вариантов.

Для публичного Rust API выбран бы Result или Option в зависимости от смысла отсутствия ошибки. Для C-совместимого интерфейса выбрал бы явно документированную структуру с фиксированным ABI. Результат — корректная семантика на уровне Rust без зависимости от не гарантированной внутренней раскладки.

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

1. Можно ли считать, что Result<&T, ()> всегда имеет размер ссылки?

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

2. Чем ниша отличается от обычного отдельного дискриминанта?

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

3. Можно ли использовать нишевую оптимизацию как часть протокола сериализации?

Нет. Внутренний layout Rust не следует считать форматом данных или ABI, если это специально не гарантировано. Сериализация должна задавать собственное представление вариантов, а FFI — использовать совместимые типы и явные правила размещения; иначе обновление компилятора, платформы или параметров оптимизации может нарушить совместимость.