Data structure methods

[julien-truffaut]

shall we implement type class methods (e.g. map, show) on data structures in cats.data or shall we get them via ops implicit classes?

[ceedubs]

Certain things (like show) are going to need an implementation somewhere. To me it seems to make sense to put the implementations on the data structure itself and then have the type class instance call through to it.

However, there's also the question of derived methods. At nescala @tpolecat, @non, some others (whose GitHub handles I don't know :( ), and I were discussing what options there might be to have derived methods available on data structures for free. It's always slightly annoyed me that in scalaz it's pretty ad hoc as to which derived type class methods are available on a given structure. I can't recall whether or not we came to a good solution. Maybe they remember?

[julien-truffaut]

I also like defining the methods in the class because it gives a better documentation and no need of special import. however, what do we do for TC like Traverse or Fold which have a lot of derived methods?

[ceedubs]

@julien-truffaut that's a good question. Hopefully some good suggestions will come out of this discussion!

[non]

I agree with @ceedubs -- I think concrete types should provide all the concrete implementations there type classes need.

This can be a bit ugly but it has many benefits:

1. Things for users are guaranteed to "just work" whenever possible.
2. You can avoid repeatedly synthesizing type class instances.
3. It makes the methods more discoverable via documentation / browsing.

Of these concerns I think (2) is the most important.

If we agree with this approach then it implies that at a minimum we should be adding === and =!= methods to our concrete types where applicable, so that they can directly do type-safe equality checking.

[stew]

@julien-truffaut seems like there in consensus here, do you think we need to do more with this issue?

[julien-truffaut]

sure I think we all agree