+

У меня такой вопрос: а почему flatMap { null } не является эквивалентным flatMap { emptySequence() } ?

Давайте сделаем, чтобы flatMap лямбда могла возвращать nullable?

mapNotNull есть (и очень удобное!), а flatMap null'ы не поддерживает. Непорядок

А зачем if(list.isEmpty) писать? Почему не if(list)? Это очень скользкая дорожка в конце которой стоит Groovy или JS. Не то, чтобы это плохо. В каких-то доменах это удобно и нужно позволять пользователю так делать (уже сейчас можно определить свой flatMap который понимает null), но это не путь для Kotlin stdlib, где работа с нулями и значениями по умолчанию
всегда explicit.

Саспенд функции, в ретрофитовском интерефейсе, по дефолту будут работать на IO диспатчере ? Нет смысле обарачивать их выполнение получается ?

А какой вред от flatMap { null } ?
Тут же нет разночтений.

А в if(list) есть разночтения? Вопрос то вообще не в этом, а в том что читатель кода не видит, что это код запросто «глотает» null, в чем огромный потенциал для ошибок. Особенно это верно про null. Ведь мы до сих пор живем рядом с огромной Java экосистемой, где NPE это одна из самых частых ошибок в реальном коде.

Здесь NPE не будет, но незаметно «проглоченный» null это еще хуже. Тут идеология Котлина простая. С null должно быть удобно работать (так он часто нужен), но работать с ним должно быть безопасно и работа с null должна быть явно видна в коде. Мы делаем иногда исключения (ref.toString и т.п.) но только в очень ограниченных случаях. И каждый раз это жесточайший компромис удобства и безопасности - всегда люди жалуются что из-за этого они пропустили ошибку в своем коде.

Если так (и, если истинная цель в том, чтобы упало KNPE), то давайте добавим flatMapNotNull для симметрии с mapNotNull?

Зачем? Какой у этого use-case? Если вы уверены что в каком-то коде не может быть null, но компилятор этого не знает и вывел nullable тип то пишите !! — это компактно и понятно.

Use-case такой: есть коллекция, и я трансформирую её. Делаю when и в зависимости от элемента возвращаю то или иное значение sequence. Есть такие входные значения, которые нужно пропустить. И у меня это condition -> emptySequence()

Ставить проверку в отдельном filter неудобно, т.к. между filter и flatMap smart cast'ы обнуляются

Есть надежда что мы научим смарт-касты проходить через filter в будущем.

Я к тому, что семантика flatMap { null } гораздо понятнее, чем if (list). У if может быть осмысленным и if (list != null) и if (!list.isEmpty()) и так далее.

А действие flatMap на null довольно понятно.
Например, fun String.match(regex: String): Array<String>?

Тут используется null для обозначения 'не найдено'. Почему нельзя match подать напрямую в flatMap? Нелогично получается

У меня тоже такие кейсы есть. Но нужды в null не испытывал. пустые sequenceOf, listOf, flowOf нормально работают.

ну и всегда можно сделать ?: sequenceOf после того же when

не вижу прям огромной нужды засорять stdlib

а вот смарткасты после фильтра было бы круто заиметь.

Stdlib должен быть универсален. в одних приложениях null всегда заменяют на пустой список, в других на какой-нибудь маркер «не найдено». Если у вас первый случай постоянно, то напишите свой extension. Для этого они и есть.

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

А какая разница что принято в приложении, если результат flatMap от этого не будет зависеть?

Ну и из смежной оперы (компилируется, не падает, работает согласно документации): listOf(2, 1).sortedBy { null }
Почему flatMap { null } считается более редким (и/или менее понятным) — неясно

Вы меня не слышите. Я уже подробно ответил почему так.  А sortedBy { null } концептуально не отличается от sortedBy { 42 } и дает такой же эффект.

При этом flatMap { emptySequence() } работает, а flatMap { null } не компилируется 😕

TL;DR: flatMap не принимает null не из-за ошибки дизайна. Это сознательное решение согласованное с дизайном всего stdlib. И никакого отношентя к тому что можно делать sortedBy nullable type это не имеет. Это из другой оперы.

Но почему тогда в дизайне нет flatMap*NotNull?

У map* вариаций (map, mapIndexed, mapTo, mapIndexedTo) есть вариации NotNull.

А у flatMap (и flatMapTo) нет вариаций flatMap(To)NotNull. Не похоже, что это согласованный дизайн