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

Код не скомпилируется: Limits нельзя использовать как dyn Limits, потому что трейт содержит ассоциированную константу MAX. Ассоциированные константы делают трейт несовместимым с динамической диспетчеризацией, даже если вызывающий код напрямую не обращается к MAX.

Для trait object значение нужно предоставить через диспетчеризуемый метод, например fn max(&self) -> usize. Если динамическая диспетчеризация не нужна, следует принимать обобщённый параметр T: Limits.

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

В Rust существуют два разных способа полиморфизма. Generics обычно используют статическую диспетчеризацию: компилятор знает конкретный тип и может сгенерировать специализированный код. Trait object (dyn Trait) предоставляет динамическую диспетчеризацию через таблицу виртуальных методов, когда конкретный тип скрыт за указателем или ссылкой.

Trait object может содержать только те элементы трейта, для которых компилятор способен построить единый интерфейс динамического вызова. Это ограничение позволяет однозначно определить layout и набор операций, доступных через vtable.

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

В Limits::accept используется Self::MAX. Для Packet компилятор знает, что это 1024, но в функции check конкретный тип скрыт за dyn Limits. Само наличие ассоциированной константы делает трейт dyn-incompatible.

Важно, что проблема возникает на типе &dyn Limits, а не только в строке, где константа читается. Поэтому удаление обращения к Self::MAX из accept не исправит код: запрещён сам trait object для такого трейта.

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

Ассоциированная константа выбирается статически по реализации трейта. У разных реализаций могут быть разные значения MAX, но у динамического объекта нет допустимого виртуального доступа к ассоциированной константе: она не является методом, который можно вызвать через vtable.

Если нужен динамический объект, константу можно заменить методом:

trait Limits {
    fn max(&self) -> usize;

    fn accept(&self, value: usize) -> bool {
        value <= self.max()
    }
}

struct Packet;
impl Limits for Packet {
    fn max(&self) -> usize { 1024 }
}

fn check(item: &dyn Limits, value: usize) -> bool {
    item.accept(value)
}

Теперь max и accept являются методами с совместимыми получателями, поэтому их можно вызывать через &dyn Limits. Цена решения — возможный виртуальный вызов max и отказ от compile-time-константы в этом интерфейсе.

Если тип должен оставаться известным компилятору, лучше использовать generics:

fn check<T: Limits>(item: &T, value: usize) -> bool {
    item.accept(value)
}

Такой вариант сохраняет статическую диспетчеризацию, потенциальную оптимизацию и доступ к T::MAX, но не позволяет собрать коллекцию значений разных реализаций в одном Vec<&dyn Limits>.

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

Предположим, сетевой сервис проверяет лимиты разных форматов пакетов. Сначала можно использовать trait Limits { const MAX: usize; } и generic-функции. Этот вариант прост и эффективен, но API не сможет принимать разные реализации через единый trait object.

Второй вариант — заменить константу методом max. Он позволяет хранить разные реализации за dyn Limits и выбирать формат пакета во время выполнения, но добавляет динамический вызов и делает значение частью runtime-интерфейса.

Третий вариант — использовать перечисление enum PacketKind с сопоставлением вариантов. Он сохраняет явный набор поддерживаемых типов и часто даёт хорошую производительность, но хуже расширяется сторонними реализациями.

Если форматы пакетов расширяются независимо от основного сервиса и выбор происходит во время выполнения, обоснованно выбрать метод max и dyn Limits. Если набор типов закрыт или критична статическая оптимизация, предпочтительнее generics либо enum.

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

Можно ли использовать ассоциированный тип через trait object, хотя ассоциированная константа запрещена?

Да. Ассоциированный тип сам по себе не запрещает trait object. Конкретное значение обычно фиксируют в типе объекта:
```
trait Source {
    type Item;
    fn get(&self) -> Self::Item;
}

fn read(source: &dyn Source<Item = u32>) -> u32 {
    source.get()
}
```
Здесь Item = u32 является частью типа trait object. Это отличается от ассоциированной константы: Rust поддерживает такое связывание типа, но не делает ассоциированные константы частью dyn-compatible-интерфейса.
Почему нельзя сделать ассоциированную константу доступной только для Self: Sized?

Ограничение where Self: Sized применимо к методам трейта и может убрать конкретный метод из интерфейса trait object. Ассоциированная константа не является методом, поэтому таким способом её нельзя исключить из проверки dyn-совместимости.

Следовательно, даже если trait object не вызывает MAX, наличие ассоциированной константы в самом трейте остаётся препятствием. Для разделения интерфейсов нужно вынести константу в отдельный трейт или заменить её методом.
Что изменится, если оставить константу, но принимать конкретный тип через generic-параметр?

Динамическая диспетчеризация больше не требуется, поэтому ассоциированная константа допустима:
```
trait Limits {
    const MAX: usize;
}

fn check<T: Limits>(value: usize) -> bool {
    value <= T::MAX
}
```
При каждом использовании check::<Packet> компилятор знает T и может разрешить T::MAX статически. Компромисс заключается в том, что функция не принимает произвольный dyn Limits; для каждого конкретного T обычно создаётся отдельная мономорфизация.