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

#[repr(u8)] фиксирует представление дискриминанта перечисления как u8 и ограничивает допустимые значения дискриминанта диапазоном этого типа. Это не означает, что всё значение перечисления занимает один байт: варианты с данными дополнительно требуют места для payload и выравнивания.

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

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

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

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

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

Обратная ошибка — считать, что repr(u8) превращает любое перечисление в однобайтное значение. Для варианта с данными это может привести к неверному размеру буфера, ошибочному сериализатору или небезопасному обмену с C-кодом.

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

Для перечисления без данных repr(u8) задаёт целочисленное представление дискриминанта. Например, значения вариантов можно безопасно сопоставлять с числовыми кодами, если сами коды помещаются в u8:

use std::mem::size_of;

#[repr(u8)]
enum Message {
    Quit = 1,
    Retry = 2,
}

fn main() {
    let code = Message::Retry as u8;
    println!("{} {}", code, size_of::<Message>());
}

В этом случае перечисление без payload обычно имеет размер, соответствующий выбранному представлению, но полагаться на это следует только в рамках явно поддерживаемого repr-контракта. У перечисления с данными u8 задаёт размер и представление тега, а не размер всего объекта: к тегу добавляются данные варианта и возможные байты padding для выравнивания.

repr(u8) также не делает произвольное число корректным значением перечисления. Нельзя без проверки преобразовать любой полученный байт в enum через небезопасное приведение или transmute: значение может не соответствовать ни одному варианту. На границе данных нужен явный разбор, обычно через функцию преобразования, которая возвращает ошибку для неизвестного кода.

Для совместимости с C обычно отдельно рассматривают repr(C), а для фиксированного целочисленного тега — подходящий примитивный repr. Выбор зависит от ABI: repr(u8) задаёт тег, но сам по себе не описывает соглашения о порядке байтов, сериализации payload или допустимых будущих вариантах.

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

Сервис хранит тип сообщения в одном байте, а дополнительные данные — в отдельном поле протокола. Вариант с repr(u8) подходит: числовые коды становятся стабильным частью формата, а декодер может отклонять неизвестные значения.

Рассматривались два варианта. Оставить обычный enum проще, но его layout нельзя использовать как бинарный контракт. Применить repr(u8) и напрямую интерпретировать любой входной байт как enum компактно, но небезопасно: неизвестный код не становится автоматически допустимым вариантом.

Выбран repr(u8) вместе с проверяющим декодером, который сопоставляет байт с известными вариантами и возвращает ошибку. Это фиксирует нужный тег, не смешивая контроль ABI с проверкой внешних данных.

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

1. Гарантирует ли repr(u8), что size_of::<Enum>() всегда равен одному байту?

Нет. Для enum без данных такое представление может дать однобайтный размер, но перечисление с payload включает и данные варианта. Размер также может увеличиваться из-за выравнивания и padding.

2. Можно ли безопасно преобразовать любой u8 в enum с repr(u8)?

Нет. repr(u8) задаёт способ представления допустимых дискриминантов, но не создаёт варианты для всех 256 значений. Внешнее число нужно проверить и преобразовать через явное сопоставление или другой безопасный валидатор.

3. Достаточно ли repr(u8) для совместимости с C-структурой, содержащей такое перечисление?

Не всегда. Атрибут фиксирует целочисленный тег, но совместимость структуры зависит также от ABI, порядка и выравнивания полей, наличия payload и соглашений конкретной платформы. Для C-взаимодействия нужно проектировать и проверять весь внешний layout, а не только размер дискриминанта.