Типа запуска, например

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

Да вообще много где можно много чего соптимизировать, но котлину сейчас явно не до того.)

Согласен. Оптимизация композиции довольно мало где нужна. Я вот только одно место знаю.

Ребят, зачастую в примерах, если функция должна просто запустить корутину и сразу вернуть результат, не дожидаясь выполнения этой корутины, то эту функцию пишут как экстеншен для CoroutineScope.

Так вот - если такая функция находится в другом классе, то приходится прибегать к with/apply, чтобы её вызвать. Как в таком случае вы поступаете - пишете экстеншен и используете with/apply или передаёте scope аргументом в эту функцию, вместо написания экстеншена? Есть вообще рекомендации, как правильно поступить в таком случае? 😅

Импортить функцию, а не обджект/компанион

Я аргументами таскаю, остальные варианты выглядят кошмарненько

Не понял, если честно ((

Тоже к такому выводу прихожу в итоге. Что вызовы через apply/with это «такое себе» )

ставим лайк в KEEP-176

Если у вас надо экстеншен вызвать, то context.run{ myObj.myFunction()} очень даже нормально.

import obj
…
with(obj) { context.f() }

=>

import obj.f
…
context.f()

import obj
…
with(obj) { context.f() }

import obj.f
…
context.f()

это только для объектов годится и я не уверен, что это даже для них хорошее решение.

Вопрос был про типичный случай двух ресиверов

Не работает 😞

(синтетический пример 😅)

А, там как раз порядок важен, надо местами scope и downloader помеять

Гм, да, так работает

А это не сильно чтение затрудняет? Мне кажется, передача явно аргументом попроще выглядит и читается полегче 🤔

Этот порядок кстати самое проблемное место для KEEP-176