Было бы здорово если б в котлине чот такое было

попроще чем свой движок саспендов

Пишите KEEP :)

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

Насколько я помню, дизайнеры языка стараются целенаправленно избегать ситуаций, когда какие-то флажки в билд-конфигурации меняли бы семантику котлин-кода с валидного на другой валидный. Чтобы всё было однозначно.

Возможно, Kotlin 2.0 таки быть когда-нибудь :)

звучит очень странно, на самом деле.
1) Исходное утверждение спорное, в каких-то проектах может и становится всё suspend, а в каких-то нет.
2) suspend-функции, хоть они и несравнимо круче обычных потоков, сложнее правильно писать чем regular, нужно хорошо прошарить корутины чтобы ими нормально пользоваться.
3) Как всё-таки отличить blocking от regular? IO понятно, а вычисление чего-нибудь тяжелого, это blocking или regular? А если от параметра зависит, будет функция тяжелой или нет?
4) И самое главное: зачем это всё? Чтобы в проекте стало на 1000 слов suspend меньше?

1. Я бы сказал что вся индустрия к этому движется, андроидные API afaik переходя на корутины, весь Srping переписали на реактивщину+корутины. Понятно что есть легаси которое никогда туда не перейдет, но я даже там где корутины как бы и не нужны (простые скрипты для ingest данных) уже тоже пишу с корутинами, потому что тот же ktor-client на них. У меня вообще корутины с первых версий везде, и я просто не пишу уже thread-на-реквест-код с тех пор, и не понимаю зачем сегодня кто-то так будет писать.

2. Не сложнее. Нужно сравнивать одинаковые операции. Оркестировать десятки потоков, передавать данные, синхронизировать, иметь что-то на подобии structured concurency с потоками куда сложнее. Создать поток и корутину одинаково просто. Работать поверх сервера который выполняет код в корутине или в треде одинаково просто. Обычно сложности возникают на стыке тредов и корутин, но это уходит в прошлое с каждым днем.

3. Если функция может выполняться долго то это уже кандитат на модификатор blocking. Лучше сделать бесполезный context switch, чем заблокировать io тред сервера, и задача этого модификатора уберечь от таких ошибок.

4. Чтобы убрать визуальный шум да, особенно в светлом будущем, где среднему разработчику не придется использовать треды, как сейчас нету в коде приложения драйверов для устройств ввода 🙂

Можно ли как-то узнать, был ли Continuation из suspendCoroutine resumed? Пытался проверить по контексту continuation.context.isActive но там true, почему-то даже после вызова`resumeWithException`

2. Про треды вопросов нет, я сравнивал что их сложнее писать чем обычный блокирующий код.

В общем, интересная идея, но я бы у себя такой флажок не применил)

Вот, набросал тест

 @Test
    fun testContinuationState() = runBlocking<Unit> {
        val scope = CoroutineScope(Dispatchers.Default + Job(coroutineContext[Job]))
        val value = suspendCoroutine<Boolean> { continuation ->
            scope.launch {
                continuation.resume(true)
                println("suspendCoroutine resumed")
                delay(1000)
                println("suspendCoroutineStillActive ${continuation.context.isActive}")
                scope.cancel()
            }
        }
        println("suspendCoroutineValue $value")
    }

Выводит

suspendCoroutine resumed
suspendCoroutineValue true
suspendCoroutineStillActive true

ЧЯДНТ?

Или suspendCoroutine использует parent context?

(нет) просто это скроют от пользователя

 @Test
    fun testContinuationState() = runBlocking<Unit> {
        val scope = CoroutineScope(Dispatchers.Default + Job(coroutineContext[Job]))
        val value = suspendCoroutine<Boolean> { continuation ->
            scope.launch {
                continuation.resume(true)
                println("suspendCoroutine resumed")
                delay(1000)
                println("suspendCoroutineStillActive ${continuation.context.isActive}")
                scope.cancel()
            }
        }
        println("suspendCoroutineValue $value")
    }

suspendCoroutine resumed
suspendCoroutineValue true
suspendCoroutineStillActive true

Ну пожалуй стоит начать с того что так suspendCoroutine не стоит использовать, он для других целей. Или это чисто для демонстрации код?

Ну это не значит что будет сгенерировано стейт машина

Для демонстрации. Из другого потока передается значение

в реале из listener'а библиотеки

Похоже там все запривачено в Continuation, никак текущий стейт не прочитаешь, чтобы не словить "java.lang.IllegalStateException: Already resumed"

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

Ну можно посмотреть на go, там функции по умолчанию имеют ассинхроность