ну так одна а не две

и вторая такая же

Ну потому что rte расширяет throwable. По идее rte есть throwable

для этого есть ковариация. Здесь у вас отношение "... есть ..." одностороннее. И такое поведение не всегда нужно

Но я не понимаю, можно ли как-то эту ковариацию по простому применить в моем случае. Не указывая f=>f

кажется можно написать identity

В моем случае просто с Functionk.id не компилируется. Может свою надо написать

Ладно. Не важно. Я вижу что FunctionK.id тоже делает f=>f. Я надеялся что компилятор может понять что id - то же самое, без всяких ф-ций

это знание компилятора не помогает строить инстансы трейтов с полиморфными методами

возможно помог бы такой тип https://github.com/manatki/manatki/blob/master/src/main/scala/manatki/free/FunK.scala

Подскажите плс, а реализцию lazy val с synchronized блокировкой после 2.11 как-то кардинально решили?

а то я тут на проде столкнулся, и немного охерел

там много чего меняли в каждом релизе

а с чем столкнулся

Просто кажется кейс с которым я столкнулся - довольно типичный. При этом лезивал на нем ведет себя как лютый баг.
И то ли я чего-то не понимаю, то ли что.
Довольно часто у тебя есть объект который используется многопоточно, у тебя есть lazy val в одном из его методов. lazy val обычно делается ради того чтобы не вычислять дважды дорогое/долгое/нагруженное вычисление.

Далее под нагрузкой много потоков заходят в метод. И все утыкаются в lazy val по synchronized, тк он делает блокировку по this.

реф

и файбер

да это понятно

о да, поправили

в 2.12 там уже специальный монитор для каждого лейзи вала