Подскажите, пожалуйста, как работают дженерики? Вот в джаве на полиморфизме и

затирке типов, в расте шаблонизация происходит, а как в скале? Я пытался погуглить, но ничего нужного так и не нашел(

также как в джаве, можно сказать

У Хорстманна хорошо про это рассказано. Scala for impatients

Скала работает на жвм и подчиняется её правилам, так что увы - type erasure. Но в скале есть хитрые способы подсовывания типов, когда ну очень уж надо. Если интересно - можно погуглить по запросу class tag in scala

Спасибо :)

А почему "увы"? Вроде затирка типов считалась офигенной штукой и дополнительной гарантией что в рантайме мы всякими ужасами не занимаемся. Или я отстал от жизни опять?

Кто-то просто не читал theorems for free

JVM же вроде вообще не имеет понятия о дженериках. Что конкретно мешает имплементировать reified generics на jvm? Насколько я знаю, в скале и джаве вообще используется микс, например, Array специализирован для примитивов. Я что-то упускаю?

reified generics эмулируются с помощью ClassTag или его более мощных аналогов

я бы даже не назвал это эмуляцией. Эмуляция подразумевает, что есть нормальный механизм, а мы используем костыль. Но user-space рефайнменты на самом деле мощнее, чем то, что могли бы запилить джаваны.

Я правильно понимаю, что это эмуляция в рантайме с рефлексией? То есть мы берем на себя то, что в reified generics сделал бы безопасно компилятор

нет, когда вы пишите val list: List[String] = List("a", "b", "c"), у компилятора или макроса достаточно информации, чтобы в той или иной форме запомнить тип элемента (без рантайм рефлексии).

Потому, что потеря информации о типах это всегда печально и приводит к неприятным ограничениям https://scastie.scala-lang.org/rvyF2itMTGqM5DGo3J93Gg

Скорее наоборот

Счастье в неведении?)

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

Сделать теги, с выразительной способностью системы типов scala приблизительно невозможно. Любые практически теги были бы несовместимы с вариантностью. ( спорно ) Почти никакие работающие в промышленных контурах системы типов с "нестираемыми женериками" не способны в HKT. В разработке мудрость зачастую в неведении, гораздо корректнее признать, что какая-то информация у вас отсутствует, чем пытаться откопать её по косвенным признакам. В данном случае, вам пришлось бы ограничивать либо систему типов, либо рантайм. Языки, с ограниченной системой типов и более развязным рантаймом есть. Но оказалось, что там информация о тайп-параметрах используется крайне редко, считается плохим тоном, хрупким решением и т.п., так что в общем случае можно сказать, что в этом вопросе scala правильное решение приняла

Ага, это интересное замечание. Я подозреваю, что с hkt это таки можно сделать совместимым, но вопрос нужно решать на уровне jvm, а не скалы Ну и опять же, стоит ли оно того, учитывая всё выше сказанное - хз

Ну многие подозревают, но никто не сделал. Самое главное, если вас не убеждают примеры scala и typescript, потому что форсированы рантаймом, не убеждают примеры haskell, ocaml и rust, потому что слишком не знаю что академичечкие, можете посмотреть на новые generic в голанге, там тоже никакой тайпинформации generic не предоставляет. Поэтому иррелевантные тайп-параметры это естественный стандарт в разработке полиморфизма сегодня

А где-нибудь ещё есть ко-/-контра-/инвариантность типов, кроме Скалы?

Котлин, тайпскрипт

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

У Явы точно нет

Не то, чтоб они меня не убеждали, просто это меня не беспокоило, я не пытался сделать собственную реализацию hkt :)