Ну как я понял, там надо делать оператор catch

catch так же работает, только на downstream flow
в итоге вместо моего

repositoryInst
   .getSomeDataFlow()
   .retryWhen {e -> true}

надо обернуться в парент флоу для прослушивания

flow<T> {
   repositoryInst.getSomeDataFlow()
}.retryWhen {e -> true}}

для catch так же
flow<T> {
   repositoryInst.getSomeDataFlow()
}.catch {e -> true}}

можно как-то сделать suppress на DSLMarker?

Почему на малом объеме данных списки работают быстрее последовательностей?
В моем примере последовательности начинают обгонять по скорости начиная с ~250_000, а при меньшем значении уступают спискам.

возможно магия JVM?

Мало памяти выделяется, меньше копирования от ресайза листа, невиртуальные вызовы

1. Потому что бенчмарки это тяжело (так наверное не очень хорошо проверять). Есть предположение, что в вашем случае могут результаты сильно поменяться если вы просто переставите ваши блоки местами.
2. Со листами интересно, ибо вещи вроде создание дополнительных объектов и хранение лямбд не особо существуют в мире листов. В какой-то момент эти факторы становятся менее значимыми, чем то, что мы постоянно пересоздаём лист.

Кстати да, здесь бенчмаркинг без прогрева

О каком прогреве идет речь?

О прогреве JVM, в результате которого код скомпилируется в более эффективный машинный код

Кажется, понял. Запустил такие же операции над списками и последовательностями прямо перед измерением и результаты поменялись: последовательности быстрее

без форков и прогрева вы не получите ни намека на реальный результат

Привет, котлинисты! Никак не могу докрутить у себя в голове generic-и.
Задача: есть сериализатор.
interface MessageSerializer<in T> where T : Message {
   fun serialize(message: T): String
}
Message - это sealed класс
Хочу сделать для сериализаторов фабрику, которая их по заданному Message будет производить:
fun getSerializer(message: Message): MessageSerializer
Как в этом методе правильно расставить дженерики?

чтобы снаружи можно было сделать factory.getSerizliaer(message).serialize(message)

Логичная версия:
fun <T : Message> getSerializer(message: T): MessageSerializer<T>

Но тогда компилятор ругается при реализации этого метода

немного странный код. а классы эти MessageSerializer<T> реализуют? или нет
лучше конечно пример кода на https://play.kotlinlang.org/ скинуть

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

преобразование идёт из обычной строки в объектный тип и обратно

Там проблема в том, что тип Т не уточняется, в отличие от типа месседжа. И в варианте getSerializer<Message>(msg) или getSerializer(maybeAuthMsg ?: regMsg) компилятор не зря перестраховывается.

Похоже что нужен unchecked cast, компилятор не видит связи между when и типами