А как они native без gc собираются делать?

https://youtu.be/nqmBlqq-k3Y?t=1772

https://youtu.be/nqmBlqq-k3Y?t=1772

Жаль, что дефрагментацию памяти не завезли.

привет ребята, как достучаться к активити-хосту с фрагмента? а то чёт выбрасывает "only safe or non null asserted calls are allowed"

привет ребята, как достучаться к активити-хосту с фрагмента? а то чёт выбрасывает "only safe or non null asserted calls are allowed"

https://t.me/android_ru

лучше бы в гугл послал)

лучше бы в гугл послал)

этим в андроидРу займутся

Выглядит просто как то что getActivity возвращает nullable переменную И человека надо просто в базовую документацию послать)

Уже пришёл оттуда, спасибо всем)

Уже пришёл оттуда, спасибо всем)

requireActivity()

если вопрос был про нулбл из getActivity()

если вопрос был про нулбл из getActivity()

Да, теперь всё хорошо Спасибо

Ребят, кто нить делал в ktor или в спринг такое обновление в контроллере, чтобы поля, которые undefined не обновлялись в null, а просто игнорировались?

можно ли как-нибудь в котлине указать явно nullability для метода из джавы, к которому у меня нет доступа?

чтобы во всех местах в проекте он подсветился как nullable

можно ли как-нибудь в котлине указать явно nullability для метода из джавы, к которому у меня нет доступа?

https://discuss.kotlinlang.org/t/automatically-generating-annotations-xml/5211/2 Увы.

кажется, я придумал решение

завернуть в свой метод?

метод X, возвращающий тип Foo! оборачиваем в екстеншн safeX(...): Foo?

ага

не самое надежное решение, но сойдет

метод X, возвращающий тип Foo! оборачиваем в екстеншн safeX(...): Foo?

я представляю будни котлин программиста, оборачивающего все java методы в safe$name

А интересно, можно ли это состряпать из поддержки jsr-305 и package-info.java в чужом пакете

можно asm'ом состряпать и патчить при загрузке

А интересно, можно ли это состряпать из поддержки jsr-305 и package-info.java в чужом пакете

это поломает кучу кода, который не подозревает о nullability

екстеншны хоть позволяют делать это инкрементально

Ну на уровне методов без модификации библиотек, видимо, только так. Но безопасности это не прибавляет нисколько

https://en.wikipedia.org/wiki/Kotlin-class_destroyer никогда бы не подумал по названию ссылки…

В 2012 году Бреслав на докладе в fprog это рассказывал ? (кстати годный доклад был)

как быть?

как быть?

убрать while(true)?

убрать while(true)?

низя, хочу бесконечный цикл и выходить из него по ретерну

как в котлин еще можно сделать бесконечный цикл в духе for (;;) { }?

Какой-то джаваскрипт кодинг-стайл

А почему нельзя просто кастовать к инту?

А почему нельзя просто кастовать к инту?

потому что касты это плохо в строго типиизрованном языке

Складываю оружие, сэр

Складываю оружие, сэр

ну серьезно, кастить в новом модном молодежном языке

async<Int> { ... }

А внутрь асинка разве что-то передается?

Какой тип у it?

Какой тип у it?

очевидно же какой для котлин программиста, Int

minutochku

Нельзя написать такой код

В котлине почти все - выражение

В т.ч. и return

И.е. return ... -> Unit

Или нет

Хз

Нельзя написать такой код

можно же, посмотри скриншоты я смог, и он даже работает с костылем ввиде throw exception

throw Exception же никогда не выполняется, ну

async { val trueCondition = true while (trueCondition) { return@async it } throw RuntimeException("FAIL") }

async получает тип Unit, потому что внутри него находится while, который является выражением, которое ничего не возвращает

throw Exception же никогда не выполняется, ну

в том то и фигня, что либо получаю варнинг, либо не компилируется, вот такой язык

Потому что внутри него находится return, который возвращает в функцию наверху

Короче, кто там паззлеры делает на конференции, пихайте этот кейс себе в доклад

async { val trueCondition = true while (trueCondition) { return@async it } throw RuntimeException("FAIL") }

это к чему? костыль ввиде експешена остался, и зачем то условие перенесено в переменную

выглядит все равно плохо

в том то и фигня, что либо получаю варнинг, либо не компилируется, вот такой язык

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

Почему бы не использовать producer?

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

ваша позиция ясна, ок

выглядит все равно плохо

Вот так разве что while (true) { it }

Возвращать прямо в асинк из вайла не получится, это как пытаться достать мозг через нос мизинцем ноги

Своего друга

Как вариант, если считаешь себя умнее компилятора то повесить supresswarning @Suppress("UNREACHABLE_CODE") throw RuntimeException("FAIL")

Как вариант, если считаешь себя умнее компилятора то повесить supresswarning @Suppress("UNREACHABLE_CODE") throw RuntimeException("FAIL")

да это очевидно, но хотелось бы от этого костыля ексепшена избавится

Причем там можно даже не исключение кидать, а возвращать значение, чтобы дженерик был Inferred

Типа, while (true) { return@async it } 0 С суппресс варнингом

Почему бы не использовать producer?

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

Типа, while (true) { return@async it } 0 С суппресс варнингом

костыльненько

Как говорится, если умник, то пи**уй в Руби

По факту там все логично, Kotlin видит что из функции может вернуться - в случае 1 Int (из return@) либо Nothing (из throw) - в случае 2 Int (из return@) либо Unit (из всего while) Дальше он выводит наиболее общий тип, в первом случае это Int, во втором Any. То что компилятор не проверят, что цикл бесконечный - ну блин, это очень узкий кейс, да и у нас тут не Coq с Idris

Как говорится, если умник, то пи**уй в Руби

спасибо, не знал такой поговорки

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

В джава нет корутин)

По факту там все логично, Kotlin видит что из функции может вернуться - в случае 1 Int (из return@) либо Nothing (из throw) - в случае 2 Int (из return@) либо Unit (из всего while) Дальше он выводит наиболее общий тип, в первом случае это Int, во втором Any. То что компилятор не проверят, что цикл бесконечный - ну блин, это очень узкий кейс, да и у нас тут не Coq с Idris

да я понимаю, ожидал что разрулится

В джава нет корутин)

да тут проблема с дженириками\определением возвращаемого значения, а не с корутинами

да тут проблема с дженириками\определением возвращаемого значения, а не с корутинами

А Java не умеет в Nothing и автокасты

Тут как бы компромис

Почитайте что такое Nothing и какие плюшки он несёт, вы удивитесь, но вы это использовали и не замечали

Дак что нет. С дженериками тут даже лучше

Просто не стоит переносить мышление написания кода на Java в Kotlin, отличия как бы есть

да тут проблема с дженириками\определением возвращаемого значения, а не с корутинами

В жабе так-то и адекватного лямбда-исчисления нет, чтобы такие кейсы крутить

Зато теперь Java втянула себе var)

Ссаные @FunctionalInterfaceы это насмешка над ФП

А компилятор ругается тоже, или только инспекция в идее?

Может, он не считает этот код недостижимым

низя, хочу бесконечный цикл и выходить из него по ретерну

Какой смысл в цикле без цикла?