Комментарии 6
Судя по проектам, которые включили #![warn(bare_trait_objects)], код от dyn Trait и правда на практике не сильно раздувается и уж точно не теряет в читабельности — например, https://github.com/ggez/ggez/commit/ec3c1e0f6dd
SIMD — отличная тема, очень нужно.
#[must_use] и стабилизация — тоже неплохо.
А вот в необходимости dyn Trait меня все-таки не убедили. Основной посыл — "мы не знаем, тут трейт объект или структура, а это влияет на производительность". Ну, влиять-то оно влияет, да, но какая разница? Это ж блин сигнатура функции, она должна говорить про типы параметров, а не требования к производительности определять.
Аргумент с ортогональностью impl Trait тоже неубедителен — в одном случае это кодогенерация, которая делает возможным прежде недоступные вещи, а другое — просто алиас для уже существующей синтаксической конструкции, которую придется деприкейтить и писать тулзы для миграции.
Это ж блин сигнатура функции, она должна говорить про типы параметров, а не требования к производительности определять.
Да, поэтому сигнатуру, которая сразу же ограничивает "а эта функция точно не сможет работать максимально быстро вне зависимости от реализации из-за отсутствия инлайнинга и т. п.", лучше делать явно видимой. Кроме того, dyn Trait не только в сигнатурах может возникать, но и, например, в структурах данных, где подобные ограничения также лучше видеть.
Аргумент с ортогональностью impl Trait тоже неубедителен — в одном случае это кодогенерация, которая делает возможным прежде недоступные вещи, а другое — просто алиас для уже существующей синтаксической конструкции, которую придется деприкейтить и писать тулзы для миграции.Аргумент с ортогональностью — он скорее не про возможности, а про обучение. У новичков разница между dyn Trait и impl Trait будет, предположительно, вызывать сильно мешьную путаницу, чем между Trait и impl Trait при использовании в местах, где могут быть оба варианта. Rust и так имеет непростую кривую обучения, так что её локальное упрощение имеет смысл даже ценой небольших миграций.
У dyn Trait ноги растут из хайпа вокруг мономорфизации, которую сейчас пытаются пихать куда надо и не надо. При этом находятся пользователи, которые не смогли в ошибки компилятора в случае попыток запихать что-то недозволенное в типаж-объект. Решение о явном зашумлении динамического полиморфизма принято из данных статистики, что статика используется намного чаще динамики (не в последнюю очередь из-за низкоуровневости проектов-объектов статистики, язык все же замена С/С++, и писать что-то динамическое просто не видят смысла , для этого есть Electron). Другого объяснения я не нахожу.
Имхо, явное, в данном случае, лучше неявного.
Отличить типаж от типа, не закапываясь в "где же он определён" бывает достаточно сложно — далеко не всегда исходники доводится читать в IDE.
И в целом очень удобно явно видеть, что "здесь у нас trait-object" (на который кроме вышеупомянутых "штрафов" скорости, действует ещё целый ряд ограничений).
Выпуск Rust 1.27