я как раз ловил проблемы, что в рантайме AnyVal был не отличим от типа над которым была обертка. - это не проблема, это то как он должен себя везти. А вместо этого он на каждый чих скатывается в свои ограничения. А точнее в пункт про cannot be used in type tests

Ну и плюс бесконечные мусорные  myval.value - чтобы достучаться до самого значения. Когда код усыпан этим - прям буэээ. А теги дают гарантию отсутствия обертки + могут быть использованы напрямую в качестве основания (а если нужно исключить это - ньютайпы - и опять с гарантией отсутствия оберток (правда обьективизация все же будет - примитивы перейдут в обьектные эквиваленты (только для ньютайпов, в тегах так же примитивы)))

ну я так понимаю, что в данном случае проблема в обращении getClass. Если этого не делать, то проблемы и не будет.

Ты не правильно понял. Это просто пример. А проблема, что класс энивал на практике в проектах дальше хеллоуворлда материализуется по каждому чиху и там уже не уследишь и никакая дисциплина не поможет)

хм, какая-то странная фича тогда :(

хм, какая-то странная фича тогда :(

Поэтому энивалы никто и не юзает (разве что код старый или человек не в курсе за теги,ньютайпы). Разве что для опсов) implicit class Ops() extends AnyVal

Энивалы юзают

Согласен, не знаю правда зачем)

Ждём opaque types

В 3.2?

А есть какие-то best practices по обработке ошибок в скале?

Bifunctor IO