Для кого-то это повод его любить, да, но я пытаюсь судить по его докладам

Он слишком уж фанатично отстаивает свои убеждения

Оффтоп, конечно, предлагаю заканчивать

И inline классы!

Странная у него декларация

У резалта

Вот как _возможно_ будет выглядеть inline классы, в данном случае Result

Вот как _возможно_ будет выглядеть inline классы, в данном случае Result

А, это объясняет его странную декларацию

а запись будет где-либо доступна? а то сейчас нет возможности подключиться

Она не youtube останется наверняка

Не думаю что её удалят сразу

а что значит, когда "get()" присваивают значение?

https://t.me/TheDailyKotlin/25 - вот трансляция если что

а что значит, когда "get()" присваивают значение?

это стандартное объявление геттера

Немного криво выглядит такая реализация

Хоть и рабочая

Зато одно поле вместо двух. В целом идея с приватным классом вполне себе клёвая.

а что значит, когда "get()" присваивают значение?

вот https://kotlinlang.org/docs/reference/functions.html#single-expression-functions и вот https://kotlinlang.org/docs/reference/properties.html#getters-and-setters

Зато одно поле вместо двух. В целом идея с приватным классом вполне себе клёвая.

Да это понятно, просто тут как будто напрашивается ещё юнион

а вот тебе и вопрос о юнионах :)

а вот тебе и вопрос о юнионах :)

Уже кто-то его задавал?

Наверняка

только что спросили об алгебраических типах — ответом было "у нас есть sealed, правда они не совмещаются с инлайн-классами".

так что считай ответа не было :D

Аа

Я просто не смотрю

ну Руслан предусмотрительно дублирует инфу, а я завтыкал, прошу прощения :)

вот https://kotlinlang.org/docs/reference/functions.html#single-expression-functions и вот https://kotlinlang.org/docs/reference/properties.html#getters-and-setters

благодарю

Тут думаю понятно

О,даааа

Для котлин нейтив бесценно

Чую, будет на границе с JNI тоскливо — каст на касте и кастом погоняется. А вообще да, можно будет тут же выкинуть kotlin-unsigned :) И с нэйтивом круто.

Чую, будет на границе с JNI тоскливо — каст на касте и кастом погоняется. А вообще да, можно будет тут же выкинуть kotlin-unsigned :) И с нэйтивом круто.

Там же обычный long/int под капотом на JVM

Да, и именно эти jint / jlong будут в сишном интерфейсе :( а он уже первым делом будет кастовать к uint32_t и uint64_t.

Народ - а можете в кратце рассказать приемущества и кейсы где было бы удобно использовать эти же inline классы? Что под капотом у нового лонг и инт, максимальные значения надеюсь будут больше?

Ну я так понимаю что примерно там же где и value types

inline-class — это чёт вроде typealias, только на самом деле на стороне котлина создаёт новый тип, а не просто добавляет новое имя существующему.

typealias Temperature = Float val temp: Temperature = 1.0 val f: Float = temp // валидно inline class Temperature(t: Float) val temp: Temperature = 1.0 val f: Float = temp // ошибка компиляции

я понял. Но вот профит так и не вижу)

я понял. Но вот профит так и не вижу)

Не будет создаваться объект-обертка на рантайме

Кажется что это чисто про перформанс

inline class Temperature(t: Float) inline class Price(cents: Float) val p: Price = Temperature(1.0) // ошибка компиляции

аналогичный пример с тайпалиасами скомпилируется

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

А какие огорчения есть инфа?

Помимо одного поля

А профит инлайна перед обычным классом — да, перформанс, на каждый обычный класс будет по два объекта (сам объект и то, что под капотом лежит), инлайн — один. и с примитивами без бокса он работать будет.

Нет, только об одном боле сказали.

?

Юнион можно было бы сделать не сложно с оверхедом

Юнион можно было бы сделать не сложно с оверхедом

Через Any? и касты?

Через Any? и касты?

Ну да, главное, чтобы инлайн классы это понимали

почему нету SAM для Kotlin-интерфейсов: "а мы думали, что всем просто хватит функциональных типов" :D

(правда, зачем они нужны при наличии функциональных типов и инлайн-классов?)

(правда, зачем они нужны при наличии функциональных типов и инлайн-классов?)

чтобы как в джаве было же

ERROR: S client not available

¯\_(ツ)_/¯ ребята, пришедшие из Kotlin/JS, не поймут

а вот и легаси в котлине — ключевое слово нужно потому, что для обычных интерфейсов sam-правила не хотят вводить, чтобы не сломать старый код

лучше бы вообще без этого

согласен

если кто-то не хочет расставаться с джавовыми привычками - пускай страдает

если кто-то не хочет расставаться с джавовыми привычками - пускай страдает

Надо делать петицию)

я готов поставить подпись, куда идти?)

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

ооо, круто

кто все эти люди??

значит неправильно помню, спасибо. :/

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

Да 100% это просто нужно было для их разработки IDEA (там же куча микса kotlin/java), поэтому и впилили

судя по результатом голосов, опрашивали питонистов

У меня возникает только один вопрос: когда релиз 1.3? Столько плюшек классных

?

Да 100% это просто нужно было для их разработки IDEA (там же куча микса kotlin/java), поэтому и впилили

inline class Predicate<T>(test: (T) -> Boolean) из джавы, насколько я понимаю, это будет видно как KFunction<Boolean, T> (или как там этот класс выглядит). вполне себе юзабельно на точке соприкосновения.

У меня возникает только один вопрос: когда релиз 1.3? Столько плюшек классных

Сказали в конце 2018-начале 2019 года. Но это не точно

судя по схемке, хрен нам, а не удобство при разработке плагинов для компилятора.

Ну если будет Common BE (Common Backend)

(JVM BE + JS BE — то, что есть сейчас, Common BE — то, что сделали, когда начали делать нэйтив, JVM / JS Codegen — в планах)

Ну если будет Common BE (Common Backend)

там, вероятно, будет уже IR, то бишь нечто сильно более низкоуровневое, чем AST. да, так и есть.

а я-то думаю, что это за PR в нэйтиве о возможности композитной сборки со взрослым котлином :)

Кажется что это чисто про перформанс

Понял. Спасибо

Очень хочется IR as public API

(оффтоп: Руслан, посмотрел недавно доклад по Ktor с BKUG — спасибо огромное, очень круто!)

@HeapyHop огромное спасибо за трансляцию, к сожалению не было возможности посмотреть

Самому

Очень хочется IR as public API

К этому все и шло