#вопрос Касательно того, как передавать обычную (не-suspend) функцию в параметр, требующий suspend-лямбду.

Начиная с версии 1.4, компилятор должен уметь автоматически конвертировать, но у меня до сих пор выдаётся ошибка "The feature "suspend conversion" is disabled"

Не понятно. Что такое параметр, требующий лямбду

У кого ещё такое было и как с этим бороться?

Ну сказал бы сразу, что речь про function reference. Так в чем проблема? не суспенд передать вместо суспенда?

Да, проблема в том что выдаётся ошибка "The feature "suspend conversion" is disabled" , хотя в настройках языка указывается версия 1.4

Вообще странно. Я такое не встречал. Я правда пока и фичу эту не использовал.

Друзья привет!
Подскажите, если у меня в Java библиотеке есть какой-нибудь статический метод вроде

public static A method(B recv, C arg1) { … }

Я могу как-то уговорить компилятор котлина считать этот метод экстеншен функцией класса B? 😀 И пользоваться им как-то так

val a: A = b.method(c)

public static A method(B recv, C arg1) { … }

val a: A = b.method(c)

Нет, можно написать свой экстеншен поверх

Ну свой то понятно. Жаль 😀
А тикет на это есть, не знаешь? Я бы подписался 😀

Я не думаю, что это реально сделать просто. Это надо к методу котлиновскую метадату прописать. Я думаю, что можно генерацию котлиновских экстеншенов можно сделать по аннотации через компайлер плагин, но это надо подождать компайлер плагинов. А что, так много этих методов?

Да нет. Просто вот наткнулся на такую ситуацию и подумал что было бы удобно 😀

Ну если разово, то инлайн расширение никому не мешает. А массово - это слишком много настроек будет

inline fun B.method(arg: C) = method(this,arg)
Чуть ли не короче аннотации

👍

есть вот такое https://github.com/kotlin/KEEP/issues/110

Спасибо, подписался 😀

класс! сам не додумался сделать их inline, а ведь это реально круто! как по мне, так очевидней аннотаций и более гибко

Друзья, если кто-то использует Xjvm-default и решил перейти на kotlin 1.4.20, готовьтесь к небольшому сюрпризу.
Если вы любите @JvmDefault и он у вас насован во все интерфейсы, вы почти наверняка получите
Kotlin: Explicit override is required for ...
Суть проблемы, насколько я понял в том, что если вы объявили метод с @JvmDefault, нужно обязательно всем наследникам-интерфейсам поставить @JvmDefault на этот же метод. Поначалу я испугался, что придётся делать именно так, как написано в выдаваемой компилятором ошибке и делать explicit override, что было бы адом кромешным. Но нет, если у вас implicit override, то тоже канает. Во всяком случае в этой версии Котлина :)
Итого - для всех explicit override под методами @JvmDefault нужно просто пройтись и проставить @JvmDefault (чего раньше не требовалось, но это не так уж страшно).

P.S. В попытках понять это, я полез в youtrack и нашёл там странные issue, в которых увидел -Xjvm-default=all-compatibility, -Xjvm-default=all и прочую недокументированную ересь :)
Как оказалось, полный набор опций такой [disable, enable, compatibility, all-compatibility, all].
Если вы не планируете использовать бинарники с JVM старше 8, то самым разумным выглядит enable, как и раньше