oleg-py
commented
6 years ago Hi, sorry for the late reply and thanks for pointing it out.
The constraint was introduced originally to avoid ambiguities with instances for concrete classes - I cannot quite control implicit priority of these, as they are in a totally separate package. So, for example, if you wanted a FunctorRaise[Either[String, ?], String], Scala would get confused between actual Either instance and a derived instance, even though ideally it would not try derivation.
I tried the number of techniques like using shapeless' Lazy and LowPriority, or mixing all implicits together, and the abstract constraint together with replacing hierarchy was picked for being not ambiguous in most cases, not polluting scope too much and, most importantly, not bringing compile times to a crawl.
OTOH it might make sense to allow a Throwable -> subclass derivation, as it's pretty commonly wanted and doesn't really require compiler to do much work (since we can't explore the subtypes of Throwable anyway). I'll experiment with that on this weekend.
I was trying out the library, it's pretty cool.
this example from the docs does not compile, because of the constraint that F[_] has to be an abstract type
Could you explain the reason for the existence of such a constraint ?