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

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

Это отличается от dyn Trait: impl Trait обычно сохраняет статическую диспетчеризацию и не требует выбора конкретного типа во время выполнения, а dyn Trait позволяет объединять разные реализации через объект трейта.

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

Подход с impl Trait решает конфликт между двумя целями: скрыть сложный внутренний тип и сохранить преимущества статической типизации. Например, тип результата цепочки итераторов может быть длинным и завязанным на детали реализации, но компилятору всё равно важно знать его конкретный тип.

Альтернатива в виде публичного конкретного типа раскрывает детали реализации и усложняет изменение API. Альтернатива в виде dyn Trait гибче, но обычно добавляет косвенный вызов, а иногда и выделение памяти.

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

Предположим, функция должна вернуть итератор, но в одной ветви создаёт диапазон, а в другой — итератор вектора. Оба значения реализуют Iterator, однако их конкретные типы различаются.

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

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

impl Trait в возвращаемой позиции означает opaque type, то есть непрозрачный для вызывающего кода, но конкретный для компилятора тип. Функция обязана возвращать один и тот же тип по всем ветвям; различаться могут только значения этого типа.

fn same(flag: bool) -> impl Iterator<Item = i32> {
    if flag { 0..3 } else { 10..13 }
}

fn dynamic(flag: bool) -> Box<dyn Iterator<Item = i32>> {
    if flag {
        Box::new(0..3)
    } else {
        Box::new(vec![10, 11, 12].into_iter())
    }
}

В same обе ветви возвращают один конкретный тип диапазона, поэтому функция корректна. В dynamic разные типы помещаются за dyn Iterator; вызывающий код работает с единым объектом трейта, но получает динамическую диспетчеризацию и стоимость упаковки в Box.

Вызывающий код функции с impl Trait не может полагаться на скрытое конкретное имя типа, но может использовать его публичные ограничения: например, методы Iterator, указанный элемент и другие объявленные bounds. При этом компилятор всё равно знает реальный тип и может мономорфизировать вызовы.

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

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

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

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

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

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

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

1. Дополнительный вопрос: может ли вызывающий код узнать скрытый конкретный тип, возвращаемый через impl Trait?

Нет, имя и внутреннее устройство скрытого типа не являются частью доступного контракта. Вызывающий код может использовать только заявленные bounds, поэтому смена конкретной реализации допустима, если сохраняются эти ограничения и семантика API.

Однако скрытый тип не превращается в произвольный trait object. Компилятор продолжает учитывать его конкретность, что позволяет статически проверять операции и обычно устраняет необходимость виртуального вызова.

2. Дополнительный вопрос: почему два вызова одной функции с impl Trait не обязаны иметь одинаковый видимый тип результата?

Для одной конкретной функции скрытый тип фиксирован в рамках её объявления, поэтому все вызовы получают один и тот же скрытый тип этой функции. Но разные функции, даже если они возвращают одинаковый impl Trait и фактически используют одинаковую структуру, имеют разные непрозрачные типы в системе типов.

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

3. Дополнительный вопрос: что делать, если разные ветви должны возвращать разные конкретные типы, но динамическая диспетчеризация нежелательна?

Обычно вводят enum, содержащий все допустимые варианты, и реализуют нужный trait для этого перечисления. Тогда размер и поведение типа известны во время компиляции, а выбор варианта выполняется через сопоставление с шаблоном.

Компромисс состоит в том, что список вариантов нужно поддерживать вручную. Если варианты должны добавляться независимо от библиотеки или заранее неизвестны, enum не подходит; тогда практичнее использовать dyn Trait, несмотря на стоимость динамической диспетчеризации.