Точнее, обойтись можно, но dyn - самое простое, да и, наверное, быстрое решение.

Если реализации заранее известны, то enum dispatch go brr.

match по енаму чаще всего быстрее dynamic dispatch, если только у тебя не 100500 вариантов енама.

Пятница, 11 Сентября, 19:00 ‐ 21:00 по Московскому времени
Rust-онлайн митап при поддержке Fluence Labs и Skyeng!
http://meetu.ps/e/Jj70H/Fjc3K/d

Информационная поддержка: https://itmeeting.ru/ - телеграм-канал с анонсами бесплатных мероприятий по разработке.

Информацию по возможным изменениям и новостям смотрите в http://t.me/ruRust_msk

FAQ:
1. Ссылка на трансляцию:
https://www.youtube.com/watch?v=GQ020NlPOec

2. Запись трансляции будет, останется по этому же адресу, можете посмотреть её позже (если на то будет воля Коннекта), но в реальном времени есть шанс задать вопросы и пообщаться с докладчиками.

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

https://docs.rs/enum_dispatch/0.3.3/enum_dispatch/
Обёртку можно через это делать.

О, спасибо за ссылку. Раньше не натыкался. Теперь dynamic dispatch буду юзать только, когда в compile time не знаю список реализаций.

Там есть пара неудобных моментов:
https://gitlab.com/antonok/enum_dispatch#troubleshooting

А чем так кардинально медленнее динамическая диспечеризация по сравнению с enum-ами? Неужели взять адрес функции из vtable по фиксированному смещению и вызвать эту функцию, сильно медленнее, чем взять дискриминант enum-а, и обработать его пачкой if-чиков пока не найдётся подходящая ветка с вызовом нужной функции?

Думаю, виртульные вызовы труднее инлайнить

Ну вот прям уж у всех методы трейтов состоят из 3-4 строчек, что бы имело смысл помечать их как inline? Или компилятор и без этой пометки может заинлайнить методы?

И без пометки может.

К тому же у динамической любой вызов это прыжок по указателю, а у enum'а может быть и что-то вроде

match en {
 Little => { /* inlined */ }
 Big => { /* ptr jump */ }
 Branched => { /* short branch inlined, other by ptr */ }
}

Может просто где-то есть бенчмарки? А то мне вот не очень очевидно что вот такое

func_ptr = vtable[2];
func_ptr(...);

сильно медленнее чем:

discr = enum.0
if discr == 0 { func_a(enum.1) }
else if discr == 1 { func_b(enum.1) }
else if discr == 2 { func_c(enum.1) }
...

func_ptr = vtable[2];
func_ptr(...);

discr = enum.0
if discr == 0 { func_a(enum.1) }
else if discr == 1 { func_b(enum.1) }
else if discr == 2 { func_c(enum.1) }
...

В доках того же enum_dispatch крейта.

Видел в начале доки довольно громкое заявление про ускорение до 10x. И мне показалось это как-то слишком круто.

Ну дочитай до бенчмарков, что ты как твиттернутый, больше трёх предложений не читаешь.
https://docs.rs/enum_dispatch/0.3.3/enum_dispatch/#the-benchmarks

Если не веришь, то качай сорцы и запускай бенчи сам.

Печально... похоже этот макрос не сработает если мой трейт уже чем-то аннотирован (#[async_trait]).
"
enum_dispatch doesn't actually process annotated traits!
However, it still requires access to the trait definition so it can take note of the trait's name, as well as the function signatures of any methods inside it.
"
А то я решил его заюзать и тут облом. Придётся подождать пока не зарелизят асинхронные трейты.

Асинк трейт разве не возвращает Box<Future>?