Там речь о том, чтобы его нельзя было вызывать без указания лимита. Но на самом деле это проблему не решает, потому что там и одного элемента можно бесконечно ждать

Проблема-то не в либе, а в том, что люди не очень думают, когда вызывают тот же toList()

Ну честно хз, код позволяет сломать себе ногу, закон Мёрфи

Точнее апи, а не код, но вы поняли

Я же говорю, что проблема скорее искусственная. Но вой был сильный, поэтому зарепортили

Решение с LimitedFlow вроде достаточно изящное. С одной стороны никакого оверхеда, с другой - надо ручками привести к лимитированному варианту перед тем как творить непотребства с терминальными операциями

Кажется, вы с понятием "release cadence" не знакомы или с чем-то попутали. ;)

Кстати да, postpone the feature, not release -- это вроде как раз не о пятилетках за три года. 😁

Кстати, о котиках: https://openjdk.java.net/projects/jdk/16/

Финальные рекорды. Финальный jpackage и SIMD API. А еще МИГРАЦИЯ НА ГИТХАБ!

Ага. Осенью KotlinConf, а весной Google IO. Надо же что-то на киноутах рассказать.

С таким решением много других проблем: неочевидный discoverability для новых пользователей, непонятная семантика в случае, например, с stateFlow.asLimitedFlow().map{}, миграция с существующих операторов etc. У каких-то операторов непонятная двойственность появится, типа, почему first есть на любом флоу, а single  — нет

Ну я же не говорю, что оно прям нужно. Мне и без него хорошо, но вот народ возмущается. Поэтому должно быть обсуждено. С map все понятно. лимит отображается в лимит. Но пользователь, разумеется может обозвать лимитированным тот, который лимитированным не является. Во всей этой дискуссии есть здоровое зерно, в том, что toList на Flow в общем случае - это вредная штука. И их надо бы убрать или оставить вот в таком виде, чтобы пользователь подписывался под тем, что он делает

А как вздумается вашему цеху
Скажем встать на юбилейную вахту
Представляешь сам какую оценку
"Голоса" дадут подобному факту

Там много было всяких трудовых упражнений.
Впрочем это всё никаким боком к Котлину уже не относится 😊

>лимит отображается в лимит

такое система типов Котлина без дублирования всех операторов или без протаскивания дополнительного типового аргумента не умеет

Как при использовании JsonTransformingSerializer модифицировать входящий JsonElement? заменить например одно поле на другое.

Потому что чтобы такое делать, нужно иметь хкт, возможно тайпклассы и не нужно иметь твердолобую уверенность, что self == лучший дизайнер языков в мире

Плюс некоторые кадры в коммьюнити 'не понимают', зачем нужны хкт в котлине, несмотря на то, что 'понимают', какая польза от них может быть в целом

Подобная ситуация у нас с List vs Sequence. В случае с Sequence у нас ещё есть куча классов, наследующих Sequence и инкапсулирующих вычисления.

интересно, в чём причина таких запретов. ещё в лямбдах и часто встречаются проблемы с вараргами. это же просто сахар для Array, что не так ?