> потому что дженерика в рантайме нет
не нравится мне этот вывод)

зачем?

ну иногда нужно получить класс дженерика

не надо

в сериализации это полезно

ясно

Нууу, я увы не настолько подкован, что бы говорить заумными словечками. Вообще скорей компилятору нужна гарантия что список нужного типа, например val list = listOf<Int>() - в локальном скоупе он понимает что за тип у колекции

И может гарантировать "что в рантайме также" (не знаю как корректно сказать) - следовательно он может приметь ряд оптимизаций

Конкретно в вальхалле под капотом ArrayList'а будет массив, у которого в заголовке есть пометка о том, что там инты. Это всё ещё не позволяет нам узнать, что listOf<List<Set<String>>>()::T::T::T == String

А я и не говорил что это нам нужно знать. Нам это важно доказать в билде либо рантайме, а как это уже не столь важно. Как я написал вполне может хватить и проверки в рантайме

У меня тут инсайд, чем закончится 2020-й:
https://twitter.com/shipovniks/status/1313423834385649666

это апомнило мне немного из нашей оперы

а ты это и бросал)

какие-то странные у нее планы по захвату мира х)

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

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

кто нибудь уже фигачил их на котлине?

дайте потрогать

Так-с, и чё это?)

Короче, в TEA часто такой паттерн есть – в ответ на Msg A нужно дозапросить данные (например, из SharedPreferences). Как обычно это решается – кидаешь Effect(Cmd) и в ответ ждёшь Msg B, и уже когда он пришёл, достаёшь из него данные и компьютишь свою логику

Coeffect – это способ избежать этой нудятины. Ты в ответ на Msg A бросаешь Coeffect<R>, и функцию (R) -> State, Effect. И коэффект сначала выполняется, а потом вызывает твою функцию и ты в шоколаде