Или вообще выкинуть информацию о тайп-параметраэ

А что если у вас тайп-конструктор реально конструирует разные типы в рантайме и они имеют разное представление

это разве не плохо?
особенно, когда по сети прилетает какой-нибудь объект, кладётся в такую коллекцию (с как раз стёртым типом) и всё проходит успешно. хотя при компиляции тайп-кейсинг бы не прошёл

Тогда если какая-то функция или модуль принимает такой тайп-конструктор, и намеревается его использовать, проконтролировать как она будет его использовать нельзя

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

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

Через сеть вам прилетают байты, а не коллекции

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

Никаких преимуществ в корректности получения данных по сети в сишарпе или сишке по сравнению с джавой или хаскелем не замечено

этот "алгоритм парсинга" может включать в себя проверку на принадлежность типу, например?

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

@waagnermann упомянутый тайп-кейсинг может казаться полезной штукой, но это прямая дорога к хрупкому коду, практика плохая и порочная.

И парсер с помощью того или иного механизма найдёт кодек.
В скале, хачкеле и расте для этого используется примерно один механим

Называемый тайпклассы/имплиситы(гивены)/трейты

спасибо за подробные ответы
перечитаю

Можете посмотреть как работают json кодеки вроде circe или бинарные вроде scodec

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

ну логгеры или метрики тегать ими можно как пример:
trait Logger[F[_], service <: Singleton with String]

class FooService[F[_]](implicit log: Logger[F, «foo-service»])
ну и потом такой  вот логгер создать.

а значение этого типа  можно через ValueOf достать, чтобы в метрики писать потом:
val saveMetrics[service <: Singleton with String](implicit vo: ValueOf[service]) = save(vo.value)
saveMetrics[«kek»] //в vo.value будет строка «кек»

зачем — чтобы не накосячить во всяких именах или чтобы работал имплисит резолюшн.
Метрики мы например текаем обжектами-компаньонами соответствующего класса

У меня была идея чтобы проверять MIN <= MAX на этапе компиляции.
Нужно для валидации строк по длине.

ну эт в доку рефайнеда тогда, там вроде было такое, без статей даже