ну логгеры или метрики тегать ими можно как пример:
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 будет строка «кек»

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

Есть что-нть в публичном доступе про это?

в тофу в исходниках ServiceLogging например, но надо копаться. А так не видел, может написать надо

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

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

а в рефайнед есть предикат Length или Size, не оч помню

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

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

Опять же нестирание тайппараметров не противоречит параметрисити, а стирание  её не обеспечивает.
И даже приколы со структурами, где у вас в рантайме сохранена информация, с каким параметром типа эта структура инициализирована, так чтобы компилятор вам поверил, в ограниченной форме вполне реализуема и в scala/haskell, и не будет ничего ломать, она требует другой фичи, для которой полезно стирание генериков - ГАДТ

Это ж тайптеги/класстеги? Зачем для них гадт?

блин на самом деле он теперь всегда ругается на матч по енуму :(

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

кот

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