You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
FunctorEmpty and TraverseEmpty (used to be FunctorFilter and TraverseFilter were moved to cats-mtl when that was extracted from cats-core, as it was one of multiple leaves for Functor.
However, when I look at these two type classes, they seem to be awfully unfit for cats-mtl, as they don't have anything at all to do with monad transformers and can't even be lifted through monad stacks. I suspect the only reason they were moved at all was to use the new composition-based type class encoding (which I agree is a good reason).
I propose moving them back along with their instances as they are really useful and we shouldn't have any trouble using the composition-based type class encoding (we already use it for things like Parallel). Interested in hearing thoughts :)
The text was updated successfully, but these errors were encountered:
I suspect the only reason they were moved at all was to use the new composition-based type class encoding
As far as I recall that was the main drive, although there might've been some technical reasons as well. I believe @edmundnoble also mentioned some kinkiness in writing laws for them. But I don't recall the detail and from the law code in cats-mtl, I didn't immediately see any technical issues (if to move them to core.) I'd say worth a try.
I missed having these classes in core a couple of times. so I'm also slightly +1 on moving them back too.
FunctorEmpty
andTraverseEmpty
(used to beFunctorFilter
andTraverseFilter
were moved tocats-mtl
when that was extracted from cats-core, as it was one of multiple leaves forFunctor
.However, when I look at these two type classes, they seem to be awfully unfit for
cats-mtl
, as they don't have anything at all to do with monad transformers and can't even be lifted through monad stacks. I suspect the only reason they were moved at all was to use the new composition-based type class encoding (which I agree is a good reason).I propose moving them back along with their instances as they are really useful and we shouldn't have any trouble using the composition-based type class encoding (we already use it for things like
Parallel
). Interested in hearing thoughts :)The text was updated successfully, but these errors were encountered: