Consistency tests for override instances

[yilinwei]

Currently we have overrides for specific methods for instances which are more efficient.

It's important that the output of the overriden method should be consistent with the output of the derived method and should be tested.

[kailuowang]

The strategy we had in the past is to add it to the laws, example. The issue with this strategy is that these tests are not the same as the more fundamental laws that usually test against abstract methods. Shall we setup a new organization to make a distinction between these two types of laws?

[peterneyens]

FWIW, this is what I played around with after we talked about creating some sort of benchmark for overridden/default implementations (see #1532 (comment)).

In essence it boils down to a type class specific wrapper that implements only the fundamental type class operations using the actual instance of the data type it wraps.

case class FoldableWrapper[F[_], A](val inner: F[A])(implicit F: Foldable[F])

object FoldableWrapper {
  implicit def foldableWrapperInstance[F[_]](implicit F: Foldable[F]): Foldable[FoldableWrapper[F, ?]] =
    new Foldable[FoldableWrapper[F, ?]] {
      def foldLeft[A, B](fa: FoldableWrapper[F, A], b: B)(f: (B, A) => B): B =
        F.foldLeft(fa.inner, b)(f)
    
      def foldRight[A, B](fa: FoldableWrapper[F, A], lb: Eval[B])(f: (A, Eval[B]) => Eval[B]): Eval[B] =
        F.foldRight(fa.inner, lb)(f)
    } 
}

Maybe we can use something like this somehow (for consistency and/or benchmarking) ?

[yilinwei]

@peterneyens I like that approach and I think we can/should generate these tests.

On a side note it's like the issue described in #1659, in that we have a behaviour we expect but we enforce it via manual checking rather than in some automated fashion.