верно, умолкаю

if (a) "hello" не выражение

Так то тут тоже есть ветвление

Так то тут тоже есть ветвление

ветвление есть, выражения нет

Если даже else есть это не выражение. Выражение возвращает булевый результат

Если даже else есть это не выражение. Выражение возвращает булевый результат

выражение просто имеет значение, былевый результат возвращают булевы выражения)

1+1 — выражение, но не Булево

Тогда все равно не понимаю твоей логики. if-else такое же выражение / невыражение как и просто if

if else ничего возвращать не обязан.

Тогда все равно не понимаю твоей логики. if-else такое же выражение / невыражение как и просто if

нет, можно написать println(if (a) "yes" else "no")

Тогда все равно не понимаю твоей логики. if-else такое же выражение / невыражение как и просто if

Ок, что будет, если ты сделаешь var a = if (true) "text"?

if else ничего возвращать не обязан.

просто удобно когда if/else — выражение не нужны ублюдские тернарные операторы

Ок, что будет, если ты сделаешь var a = if (true) "text"?

ошибка компиляции

Ок, что будет, если ты сделаешь var a = if (true) "text"?

Будет бред

Будет бред

В случае, если var a = if (true) "text" else "not text" Будет работать.

Ок, что будет, если ты сделаешь var a = if (true) "text"?

По твоей логике, если там любой else добавить все равно будет выражение

Ок, что будет, если ты сделаешь var a = if (true) "text"?

жаль null по-дефолту не возвращает)

По твоей логике, если там любой else добавить все равно будет выражение

По какой логике? Речь о том, как язык работает.

жаль null по-дефолту не возвращает)

не жаль, лол

По твоей логике, если там любой else добавить все равно будет выражение

По моей. Да, уточняю: если в else-ветке есть выражение

жаль null по-дефолту не возвращает)

ни разу не жаль

жаль null по-дефолту не возвращает)

null не должно быть в языке в принципе

тоже верно

вообще я хз чё вы спорите, вот в Rust нормально сделали if/else выражением, язык от народа

null не должно быть в языке в принципе

Если язык его умеет обрабатывать, как Котлин, почему нет?

Если язык его умеет обрабатывать, как Котлин, почему нет?

потому что не нужен

По моей. Да, уточняю: если в else-ветке есть выражение

Я понял твою мысль. Но это частный случай. if-else может ничего не вернуть.

потому что не нужен

есть Option/Maybe, всё остальное от лукавого

есть Option/Maybe, всё остальное от лукавого

В чём решающая разница?

В чём решающая разница?

в том что null — какое-то специальное значение вшитое в язык

а Option — обычная структура данных, такая же как любая другая

в том что null — какое-то специальное значение вшитое в язык

это компромисс. Вроде и опшнал, но бесплатный.

можно, кстати, написано опшнал на инлайновых классах)

это компромисс. Вроде и опшнал, но бесплатный.

щас бы на опшнлах экономить

щас бы на опшнлах экономить

всегда на чём-то приходится экономить

щас бы на опшнлах экономить

А если в опшионалах нуллы? ?

а Option — обычная структура данных, такая же как любая другая

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

Я понял твою мысль. Но это частный случай. if-else может ничего не вернуть.

if-else может не вернуть ничего, только если в одной из веток полетит исключение (выражение будет иметь тип Nothing). Тогда на результат по ходу пьесы всем уже плевать, до потребителей дело не дойдёт. во всех остальных случаях какое-то значение да результатом будет, даже если это Unit.

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

не понял

что значит «у каждого свой опшнал»

всегда на чём-то приходится экономить

тогда имеет смысл экономить не на спичках

if-else может не вернуть ничего, только если в одной из веток полетит исключение (выражение будет иметь тип Nothing). Тогда на результат по ходу пьесы всем уже плевать, до потребителей дело не дойдёт. во всех остальных случаях какое-то значение да результатом будет, даже если это Unit.

а если в какой-то ветке цикл или if-не-выражение?

Если правильно понял мысль, то у языка А и языка Б разные опшионалы будут, а null — он везде null (хотя, на самом деле нет).

СТОЙТЕ!!!

не понял

ну типа я недавно когда игрался написал свой, в arrow еще один

))

тогда имеет смысл экономить не на спичках

Далеко не всегда это спички. Это сравнимо с итераторами, например.

ну типа я недавно когда игрался написал свой, в arrow еще один

так не пиши свой) используй arrow)

ну типа я недавно когда игрался написал свой, в arrow еще один

Потому что его нет в stdlib

А тот что в java, эх не будем об инвалидах

вот и я о том же

а если в какой-то ветке цикл или if-не-выражение?

>>> val a = if (true) 5 else for(x in 1..5) println(x) >>> val b = if (false) 5 else for(x in 1..5) println(x) 1 2 3 4 5 >>> b kotlin.Unit >>> a 5

если бы даже добавили его в stdlib, то все равно нашлись бы люди, которым еще надо чтобы он был Аппликативом или еще че угодно

>>> val a = if (true) 5 else for(x in 1..5) println(x) >>> val b = if (false) 5 else for(x in 1..5) println(x) 1 2 3 4 5 >>> b kotlin.Unit >>> a 5

Мне кажется, REPL работает как-то иначе, минуя некоторые проверки)

Мне кажется, REPL работает как-то иначе, минуя некоторые проверки)

Возможно, ты прав, ибо val a = if (true) 5 тоже выполнилось.

если бы даже добавили его в stdlib, то все равно нашлись бы люди, которым еще надо чтобы он был Аппликативом или еще че угодно

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

Что вообще значит не выражение? Всё - выражение, и все приводится к типу Any в конце концов

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

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

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

хочу маленькую, модульную stdlib :/

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

ну в целом сделать аппликативом чужой опшнл не проблема по сути

просто не будет единого интерфейса "аппликатив"

будут просто экстеншн-функции конкретно для опшнла

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

Тот пропосал - какаха, без HKT какие вообще тайп классы

пропосал не какаха, заебись пропосал

Мне кажется, REPL работает как-то иначе, минуя некоторые проверки)

но справедливости ради, val ... = if ... else for ... работает и в try.kotl.in

ERROR: S client not available

Тот пропосал - какаха, без HKT какие вообще тайп классы

они ж там в рамках своей либы эмулируют HKT

Тот пропосал - какаха, без HKT какие вообще тайп классы

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

Подскажите как такую штуку правильно написать?

Тот пропосал - какаха, без HKT какие вообще тайп классы

Перечитал пропозал - там и HKT тоже есть

как-то вообще иначе, должен быть отдельный способ для дженерик-типов

https://stackoverflow.com/a/11668644/3050249

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

сложна

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

откуда оно тип возьмёт?) не reified же.

Думал что реифайд)

это Jackson?

именно

HKT - что это такое

Higher Kinded Types

опять вы со своими HKT

нахера они?)

вы хотите монады?

Получилось так: fun String.jsonToMap(): Map<String, *> { return ObjectMapper().readValue<Map<String, *>>(this, object : TypeReference<Map<String, *>>() {}) }

Получилось так: fun String.jsonToMap(): Map<String, *> { return ObjectMapper().readValue<Map<String, *>>(this, object : TypeReference<Map<String, *>>() {}) }

закешируй референс)

fun <reified T> String.jsonToMap(): Map<String, T> { return ObjectMapper().readValue<Map<String, T>>(this, T::class.java) } не катит ?

fun <reified T> String.jsonToMap(): Map<String, T> { return ObjectMapper().readValue<Map<String, T>>(this, T::class.java) } не катит ?

нет, там будет сырой тип

ну логично это же для внешнего апи, я так полагаю юзер руками будет это дергать в виде "somejson".jsonToMap<Data>()

или нет ?

ну логично это же для внешнего апи, я так полагаю юзер руками будет это дергать в виде "somejson".jsonToMap<Data>()

jsonToMap<Data<A, B>>() и досвидули

с чего вдруг? ты же явно укажешь и A и B

с чего вдруг? ты же явно укажешь и A и B

а внутри функции возьмёшь class literal

и они вообще не важны на том уровне, важно знать информацию о T. он все равно будет виден как Data<*, *>

и они вообще не важны на том уровне, важно знать информацию о T. он все равно будет виден как Data<*, *>

Почему не важны? А если нужен List<Data>?

если нужно просто разобрать как дерево, это можно проще сделать, я думаю)