(к вопросу про релиз)

sam в котлин интерфейсы не завезли

ой, действительно :)

разобрался, этот Function0<T>

функциональные или какие?

разобрался, этот Function0<T>

я слишком давно не писал на джаве и забыл как там это делается

разобрался, этот Function0<T>

крутой постфикс 0

У меня переодически горит от дововод почему sam не нужен в котлине, и что его можно заменить на typealias. Но при этом typealias не существует в рантайме, да и в компайлтайме компилятор тоже не рассматривает алиасы как самостоятельные типы

можно пример typealias?

typealias SomeShitSupplier = () => SomeShit

обязательно в переменную присваивать?

?

У меня переодически горит от дововод почему sam не нужен в котлине, и что его можно заменить на typealias. Но при этом typealias не существует в рантайме, да и в компайлтайме компилятор тоже не рассматривает алиасы как самостоятельные типы

а какие там доводы кстати?

а в чем их довод?

сразу лямбдой же более секси

это тоже удивило что функциональные классы лямбдочкой не закрыть

Ну типо нахера объявлять interface SomeShitSupplier { fun supply(): SomeShit } когда можно сделать алиас

а почему бы две возможности не оставить

Но при этом компилятор не говорит что ты написал херню вроде: typealias Foo = Int typealias Bar = Int fun fooProcessing(foo: Foo) val bar: Bar = 1 fooProcessing(bar)

Ну полная же дичь

Но при этом компилятор не говорит что ты написал херню вроде: typealias Foo = Int typealias Bar = Int fun fooProcessing(foo: Foo) val bar: Bar = 1 fooProcessing(bar)

Странно, что у разрабов не горит с такого

Вот и я о том же

А может и горит и скоро потушат

Да кого там

ни разу не видел тайпалиас в коде

видимо слишком advanced

ни разу не видел тайпалиас в коде

Удалить нахер из языка!111

Удалить нахер из языка!111

только после рекурсий

Но вообще да не понятно, на кой нужен typealias без путизависимых типов

я думал он просто для читаемочти

типа define в си

Но вообще да не понятно, на кой нужен typealias без путизависимых типов

ну да получается в случае функциональных интерфейсов мы объявляем два интерфейса OnCompleteInterface{ onComplete() } OnFailInterface{ onFail() } присваеваем их в переменные, жанглируем ими и не можем перепутать когда отправляем как callback куда-нибудь а в случае typealiases мы можем перепутать и отправлять onFail в onComplete так как типы будут одинаковые () -> Unit

правильно?

правильно жОнглируем

правильно?

именно

ну да получается в случае функциональных интерфейсов мы объявляем два интерфейса OnCompleteInterface{ onComplete() } OnFailInterface{ onFail() } присваеваем их в переменные, жанглируем ими и не можем перепутать когда отправляем как callback куда-нибудь а в случае typealiases мы можем перепутать и отправлять onFail в onComplete так как типы будут одинаковые () -> Unit

> OnCompleteInterface > OnFailInterface сложно придумать названия хуже

> OnCompleteInterface > OnFailInterface сложно придумать названия хуже

да названия не причем

> OnCompleteInterface > OnFailInterface сложно придумать названия хуже

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

@Harmonizr

о, привет

Драсте

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

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

Звучит как newtype

Звучит как newtype

Его и делают, только назвали инлайн классом с расчётом на то, что в будущем, возможно, можно будет больше одного свойства в них делать.

Его и делают, только назвали инлайн классом с расчётом на то, что в будущем, возможно, можно будет больше одного свойства в них делать.

Моя мечта - чтобы вместе с контрактами, тайпклассами и inline-что-там-они-еще-придумают-с-инлайном запилили что-то вроде liquidhaskell для промышленного разработчика.

Ну и чтобы контракты были не просто припаркой к IDE, а чем-то мощным, основанным на какой-нибудь продвинутой логике

Я сомневаюсь, потому что AA -- не дженерик.

Я сомневаюсь, потому что AA -- не дженерик.

Да и BB тоже

Где можно подписаться на новости котлина?

кроме твиттера

https://t.me/TheDailyKotlin

спасибо

Добрый день. Вопрос скорее теоретический: Есть у меня желание объявить в Kotlin предикат always, который для любого входного параметра возвращает true. Пока получилось только так: typealias P<A> = (A) -> Boolean val always: P<*> = { _ -> true } Есть ли возможность сделать то же самое, но без танцев с typealias? Как-нибудь можно написать сигнатуру (*) -> Boolean?

Добрый день. Вопрос скорее теоретический: Есть у меня желание объявить в Kotlin предикат always, который для любого входного параметра возвращает true. Пока получилось только так: typealias P<A> = (A) -> Boolean val always: P<*> = { _ -> true } Есть ли возможность сделать то же самое, но без танцев с typealias? Как-нибудь можно написать сигнатуру (*) -> Boolean?

val always = { _: Any? -> true }

val always = { _: Any? -> true }

Да, для данного частного случая это примерно одно и то же, хотя тип у { _: Any? -> true } будет (Any?) -> Boolean, а не (*) -> Boolean Более общий вопрос заключается в том, как быть с вариантностью in и out для сигнатур функциональных типов. В Java можно объявить такую конструкцию: <R> Stream<R> map(Function<? super T, ? extends R> mapper); то есть map принимает на вход функцию, контрвариантную по своему параметру и ковариантную по результату. В Kotlin функции, передаваемые в map инвариантны: public fun <T, R> Sequence<T>.map(transform: (T) -> R): Sequence<R> Хотя похоже, что в Kotlin сами функциональные типы контрвариантны по своим параметрам и ковариантны по результату. Иначе я не могу понять, почему компилируется вот этот код: fun main(args: Array<String>) { fun test(f: (Double) -> Number): Nothing = TODO() val f: (Number) -> Double = Number::toDouble test(f) }

Да, для данного частного случая это примерно одно и то же, хотя тип у { _: Any? -> true } будет (Any?) -> Boolean, а не (*) -> Boolean Более общий вопрос заключается в том, как быть с вариантностью in и out для сигнатур функциональных типов. В Java можно объявить такую конструкцию: <R> Stream<R> map(Function<? super T, ? extends R> mapper); то есть map принимает на вход функцию, контрвариантную по своему параметру и ковариантную по результату. В Kotlin функции, передаваемые в map инвариантны: public fun <T, R> Sequence<T>.map(transform: (T) -> R): Sequence<R> Хотя похоже, что в Kotlin сами функциональные типы контрвариантны по своим параметрам и ковариантны по результату. Иначе я не могу понять, почему компилируется вот этот код: fun main(args: Array<String>) { fun test(f: (Double) -> Number): Nothing = TODO() val f: (Number) -> Double = Number::toDouble test(f) }

Так * - означает не кванитифицированный тип, т/е ограниченный Object сверху, т/е считай тем же Any, Any? если учитывать null, т/е все то же.

Да, для данного частного случая это примерно одно и то же, хотя тип у { _: Any? -> true } будет (Any?) -> Boolean, а не (*) -> Boolean Более общий вопрос заключается в том, как быть с вариантностью in и out для сигнатур функциональных типов. В Java можно объявить такую конструкцию: <R> Stream<R> map(Function<? super T, ? extends R> mapper); то есть map принимает на вход функцию, контрвариантную по своему параметру и ковариантную по результату. В Kotlin функции, передаваемые в map инвариантны: public fun <T, R> Sequence<T>.map(transform: (T) -> R): Sequence<R> Хотя похоже, что в Kotlin сами функциональные типы контрвариантны по своим параметрам и ковариантны по результату. Иначе я не могу понять, почему компилируется вот этот код: fun main(args: Array<String>) { fun test(f: (Double) -> Number): Nothing = TODO() val f: (Number) -> Double = Number::toDouble test(f) }

Используются модификаторы out/in для ко/контр-вариативности

и доку прочитай

Да, для данного частного случая это примерно одно и то же, хотя тип у { _: Any? -> true } будет (Any?) -> Boolean, а не (*) -> Boolean Более общий вопрос заключается в том, как быть с вариантностью in и out для сигнатур функциональных типов. В Java можно объявить такую конструкцию: <R> Stream<R> map(Function<? super T, ? extends R> mapper); то есть map принимает на вход функцию, контрвариантную по своему параметру и ковариантную по результату. В Kotlin функции, передаваемые в map инвариантны: public fun <T, R> Sequence<T>.map(transform: (T) -> R): Sequence<R> Хотя похоже, что в Kotlin сами функциональные типы контрвариантны по своим параметрам и ковариантны по результату. Иначе я не могу понять, почему компилируется вот этот код: fun main(args: Array<String>) { fun test(f: (Double) -> Number): Nothing = TODO() val f: (Number) -> Double = Number::toDouble test(f) }

Хм, удивительное рядом, ты прав, эти модификаторы можно использовать только при описании классов/интерфейсов.

и доку прочитай

Так потому здесь и спрашиваю, что в доке не нашёл, как использовать * и ко/контрвариантность в сигнатурах функциональных типов. Хотя эксперименты показали, что в Kotlin это, похоже, не сильно нужно.

Так потому здесь и спрашиваю, что в доке не нашёл, как использовать * и ко/контрвариантность в сигнатурах функциональных типов. Хотя эксперименты показали, что в Kotlin это, похоже, не сильно нужно.

* - любой тип, in\out - при объявлении дженерика

Так потому здесь и спрашиваю, что в доке не нашёл, как использовать * и ко/контрвариантность в сигнатурах функциональных типов. Хотя эксперименты показали, что в Kotlin это, похоже, не сильно нужно.

<R> Stream<R> map(Function<? super T, ? extends R> mapper); вот для этого в доке прям с примером

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

<R> Stream<R> map(Function<? super T, ? extends R> mapper); вот для этого в доке прям с примером

Ок. А где в доке примеры, рассказывающие, почему в коде: typealias F<A, B> = (A) -> B fun main(args: Array<String>) { val f: F<in Double, out Number> = { it } val f2: (in Double) -> out Number } строчка val f компилируется, а следующая за ней - нет? С точки зрения алиасинга типов, эти две строчки - одно и то же

Ок. А где в доке примеры, рассказывающие, почему в коде: typealias F<A, B> = (A) -> B fun main(args: Array<String>) { val f: F<in Double, out Number> = { it } val f2: (in Double) -> out Number } строчка val f компилируется, а следующая за ней - нет? С точки зрения алиасинга типов, эти две строчки - одно и то же

val f2: (in Double) -> out Number

тут вроде ошибка синтаксиса

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

val f: F<in Double, out Number> = { it }

тут ты явно задаешь тип F<in Double, out Number>

тут вроде ошибка синтаксиса

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

Синтаксис декларации функции более бедный просто

Хотя и не понятно до конца почему

inline alias потому что еще не написали. (шутка)

соглашусь с вами Andrey @fogone

inline alias потому что еще не написали. (шутка)

Так алиасов вообще после компиляции не существует, впрочем как и генериков, и вариантностей :)

inline alias потому что еще не написали. (шутка)

тайп аляс как раз просто заменять то что справа, на о что слева

по ситу инлайн)

Так алиасов вообще после компиляции не существует, впрочем как и генериков, и вариантностей :)

+

Так алиасов вообще после компиляции не существует, впрочем как и генериков, и вариантностей :)

Ну да, только постановка работает не в текстовом режиме, а на уровне типов, видимо из за этого работает

https://store.raywenderlich.com/products/kotlin-apprentice нашел такую книгу ?

че как она

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

В случае с обычными типами, use-site variance может только повторять declaration-site (но на это есть инспекция), если он ему противоречит -- это ошибка компиляции: class F<in T, out R> val redundant: F<in Double, out Number> // Projection is redundant: the corresponding type parameter of F has the same variance val bad: F<out Double, in Number> // Projection is conflicting with variance of the corresponding type parameter of FooА в функциональных типах действительно уже "прибита" declaration-site variance. Т.е. (T) -> R это с точки зрения вариантности F<in T, out R> Соответственно, use-site variance для них не имеет смысла: она или повторяет declaration-site (и тогда это просто излишний код), либо противоречит ей (и тогда это ошибка). Поэтому разрешать in/out на аргументах функциональных типов нет никакого смысла, проще запретить, чтобы не путать людей.

Щас залез, скачал clion, захотел потыкать kotlin/native. Очень удивило многообразие непонятно названных функций с непонятным назначением и совершенно без малейшего описания. Так и планируется оставить? Или пока он не зарелизится, будет ходить с кишками наружу?

Щас залез, скачал clion, захотел потыкать kotlin/native. Очень удивило многообразие непонятно названных функций с непонятным назначением и совершенно без малейшего описания. Так и планируется оставить? Или пока он не зарелизится, будет ходить с кишками наружу?

А примеры функций можно?