Skip to content

Consider using a composition based encoding for some type classes to avoid implicit collisions #2400

Open
@LukaJCB

Description

@LukaJCB

We've already adopted this pattern for a few of our type classes to avoid the well known problem that inheritance based type classes bring. All of cats-mtl, as well as Representable, Parallel and NonEmptyParallel already make use of this encoding and can therefore be safely used with the other more canon type classes.

If we look closely at the cats typeclass diagram, we can see which of our type classes could potentially benefit and the important ones seem to be Traverse, CoflatMap and Distributive, which all extend Functor. Another candidate could be Alternative, which one might want to use together with Monad, though I think it's less of a problem, since you can just require MonoidK instead.
And even less urgent, Monad currently has 3 subclasses, Bimonad, MonadError and CommutativeMonad. There could potentially be an issue if you wanted two of those together, but I think it's highly unlikely.

I think we could provide this enhancement without breaking source compatibility and should think about it for our next major version :)

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions