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

Ограничение Item = u8 фиксирует ассоциированный тип итератора: функция принимает только такие итераторы, у которых Item ровно равен u8. Поэтому внутри функции компилятор знает тип каждого элемента и разрешает операции, требующие именно u8.

Одного ограничения Iterator недостаточно: оно гарантирует наличие метода next, но не сообщает, какой тип возвращается внутри Option<Self::Item>.

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

Ассоциированные типы позволяют трейту объявить тип, который определяется реализацией этого трейта. Для Iterator это Item: конкретный тип итератора выбирает, элементы какого типа он выдаёт.

Такой подход удобен для трейтов, где у конкретного реализующего типа должен быть один естественный связанный тип. Ограничение вида Item = u8 использует этот контракт в обобщённом коде и превращает неизвестный I::Item в известный тип.

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

Функция, работающая с байтами, должна отличать итератор байтов от произвольного итератора. Если написать только I: Iterator, компилятор не сможет считать элементы байтами: ими могут быть числа, ссылки, строки или пользовательские типы.

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

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

Запись I: Iterator<Item = u8> состоит из двух частей: I реализует Iterator, а проекция I::Item обязана быть равна u8. Это именно ограничение равенства ассоциированного типа, а не обычный bound вроде I::Item: SomeTrait.

Минимальный пример:

fn sum_bytes<I>(iter: I) -> u8
where
    I: Iterator<Item = u8>,
{
    iter.fold(0, |sum, byte| sum.wrapping_add(byte))
}

fn first<I>(mut iter: I) -> Option<I::Item>
where
    I: Iterator,
{
    iter.next()
}

В sum_bytes переменная byte имеет тип u8, поэтому доступны операции для u8. В first тип элемента остаётся неизвестным, но функция всё равно корректна: ей достаточно вернуть значение как I::Item.

Это ограничение проверяется на этапе компиляции. Итератор с Item = &u8 ему не соответствует, хотя ссылки указывают на байты: &u8 и u8 — разные типы. Для такого источника можно явно скопировать значения, например преобразовать итератор через copied().

Item = u8 не меняет сам механизм вызова методов. Если функция обобщённая по I, для конкретных типов обычно создаются специализированные варианты машинного кода; ограничение лишь сужает множество допустимых I. Если нужен именно динамический источник, можно использовать объект трейта с уточнённым ассоциированным типом, например dyn Iterator<Item = u8>, но тогда вызовы выполняются через динамическую диспетчеризацию.

Точный bound обычно предпочтительнее, когда алгоритм действительно определён только для байтов. Если алгоритм способен работать с любым Item, не следует искусственно фиксировать его в u8: это уменьшит повторное использование функции.

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

В библиотеке реализуется расчёт контрольной суммы по входному потоку байтов. Источником может быть срез, файл или сетевой буфер, представленные разными типами итераторов.

Рассматривались три варианта:

Принимать только Iterator и преобразовывать каждый элемент вручную. Это максимально общий интерфейс, но функция не получает гарантии, что вход вообще состоит из байтов; потребуется отдельная логика преобразования и обработки ошибок.
Принимать Iterator<Item = u8>. Вариант сразу выражает контракт, отбрасывает неподходящие типы на этапе компиляции и сохраняет обобщённость без привязки к конкретному контейнеру.
Принимать dyn Iterator<Item = u8>. Это позволяет хранить разные источники за одним типом и выбирать их во время выполнения, но добавляет динамическую диспетчеризацию и обычно менее удобен для горячего обобщённого пути.

Для самой функции контрольной суммы выбран Iterator<Item = u8>. Ей не требуется хранить источник за единым динамическим типом, зато важно получить строгую проверку байтового контракта и сохранить возможность эффективной компиляции для разных итераторов.

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

Вопрос: Подойдёт ли итератор с Item = &u8 для параметра с bound Item = u8?

Ответ: Нет. Ассоциированный тип ограничивается точным равенством, поэтому &u8 не удовлетворяет требованию u8. Даже если ссылка указывает на байт и значение можно получить разыменованием, компилятор не выполняет такое преобразование автоматически для проверки equality-bound.

Если алгоритм должен принимать ссылки, контракт следует объявить как Iterator<Item = &u8> с подходящими lifetime-ограничениями. Если нужны значения, вызывающая сторона может явно применить преобразование вроде copied() или cloned() в зависимости от свойств элемента.
Вопрос: Чем Item = u8 отличается от ограничения Item: Into<u8>?

Ответ: Item = u8 допускает только один тип элемента — u8. Item: Into<u8> допускает разные типы, если каждый из них умеет преобразовываться в u8, например некоторые числовые или пользовательские типы.

Это не взаимозаменяемые контракты. Равенство сохраняет точный тип и не требует преобразования, тогда как Into<u8> расширяет API, но может привести к потере диапазона или скрыть важную семантику преобразования. Кроме того, Into не означает, что преобразование проверяет переполнение: конкретная реализация трейта определяет его поведение.
Вопрос: Достаточно ли bound Iterator<Item = u8> для использования метода, требующего ExactSizeIterator?

Ответ: Нет. Эти ограничения независимы. Iterator<Item = u8> фиксирует только тип элементов, а ExactSizeIterator гарантирует дополнительные свойства, включая возможность получить точную длину оставшейся последовательности через его контракт.

Если алгоритму нужна точная длина, это необходимо выразить отдельным bound, сочетая ограничения на Iterator и ExactSizeIterator. Факт, что элементы имеют тип u8, ничего не говорит о возможности заранее узнать количество элементов.