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

Возвращаемый impl Iterator<Item = u32> означает один конкретный, но скрытый тип, выбранный на этапе компиляции для всей функции. Ветви if возвращают разные конкретные типы: Range<u32> и Filter<...>, поэтому код не компилируется. impl Trait скрывает тип от вызывающего кода, но не превращает несколько типов в один.

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

Скрытый возвращаемый тип нужен для API, которые хотят использовать преимущества статической диспетчеризации, но не раскрывать сложные внутренние типы вроде цепочек адаптеров итераторов. Это особенно важно для итераторов: комбинация map, filter и take порождает вложенный конкретный тип, который неудобно указывать вручную.

Подход решает проблему сокрытия реализации без обязательного перехода к Box<dyn Trait>. При этом компилятор по-прежнему знает конкретный тип и может мономорфизировать вызовы.

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

В каждой точке возврата функции с impl Trait должен быть совместимый один скрытый тип. Условия времени выполнения не могут выбрать между несколькими типами, потому что размер и структура возвращаемого значения должны быть известны компилятору.

Неверное ожидание состоит в том, что impl Iterator работает как динамический объект трейта. Для динамического выбора разных реализаций нужен другой механизм: например, Box<dyn Iterator<Item = u32>> или собственный перечисляемый тип.

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

impl Trait в позиции возвращаемого типа является непрозрачным конкретным типом. Вызывающий видит только гарантированный интерфейс Iterator<Item = u32>, а компилятор внутри функции фиксирует один фактический тип.

В примере 0..10 имеет тип Range<u32>, тогда как вызов filter создаёт другой тип адаптера. Даже если оба значения реализуют один и тот же трейт и имеют одинаковый Item, этого недостаточно: реализация трейта не изменяет идентичность конкретного типа.

Для динамической диспетчеризации можно вернуть объект трейта:

fn numbers(only_even: bool) -> Box<dyn Iterator<Item = u32>> {
    if only_even {
        Box::new(0..10)
    } else {
        Box::new((0..10).filter(|x| x % 2 == 0))
    }
}

Здесь обе ветви приводятся к одному типу Box<dyn Iterator<Item = u32>>. Цена решения — косвенный вызов методов и обычно выделение памяти в куче для размещения конкретного итератора.

Альтернатива без динамической диспетчеризации — определить enum, содержащий оба варианта, и вручную реализовать для него Iterator. Это сохраняет статический выбор и не требует виртуального вызова, но увеличивает объём кода и связывает API с перечислением поддерживаемых вариантов.

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

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

Библиотека предоставляет функцию построения потока записей. Для обычного режима нужен Map, а для режима с фильтрацией — Filter<Map<...>>. Попытка вернуть impl Iterator напрямую приводит к ошибке из-за разных типов ветвей.

Рассматривались два варианта. Box<dyn Iterator> проще расширять и скрывает все варианты, но добавляет косвенную диспетчеризацию и потенциальное выделение памяти. enum сохраняет статическую диспетчеризацию и предсказуемые накладные расходы, но требует отдельной реализации Iterator и изменения перечисления при добавлении нового режима.

Для небольшого внутреннего API выбран Box<dyn Iterator>: число вызовов невелико, а простота важнее максимальной производительности. Для горячего участка обработки выбран enum, поскольку набор вариантов фиксирован, а лишняя косвенная диспетчеризация недопустима.

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

Означает ли impl Trait в аргументе функции один конкретный тип для всех вызовов?

Нет. В позиции аргумента impl Trait фактически задаёт обобщённый параметр: разные вызовы могут передавать разные типы, реализующие нужный трейт. Например, fn consume(x: impl Iterator<Item = u32>) может быть вызвана с Range<u32> и с типом, созданным filter; внутри одного вызова тип параметра всё равно один.
Можно ли вернуть разные типы из разных функций с одинаковым impl Trait?

Да. Ограничение действует отдельно для каждой функции. Две функции могут скрывать разные конкретные типы за одинаковой записью impl Iterator<Item = u32>, но результат одной функции нельзя напрямую считать тем же конкретным типом, что и результат другой.
Всегда ли Box<dyn Iterator> требует выделения памяти в куче?

Обычная конструкция Box::new(iterator) размещает конкретный итератор в куче, поэтому для такого решения выделение обычно присутствует. Сам объект dyn Iterator также использует динамическую диспетчеризацию через таблицу методов; если критичны накладные расходы, следует рассмотреть enum или другой статически известный тип.