RULE PROPOSAL: Relax parameters to supertype

[diesalbla]

The goal here is to have a rule to relax the requirements on input method parameters, whenever the extra features of a subtype are not used, and to generalise them to the super-type.

Problem Statement

Suppose the following hold:

• Ann is a trait or class, that declares some public methods, and Bob is another trait or class that extends from Ann.
• We have trait Fili, which is not related by subtyping to Ann or Bob, which defines a method def kili(edo:: Bob) that takes as input parameter a value edo of type Bob.
• Suppose that all the implementations (and overriding ones) of kili only uses from edo the methods or values defined in the super-type Ann, and nowhere does it use the extra capabilities of the Bob class.

The goal, then, is to rewrite the kili method from the Fili trait, so that the type of edo is changed to Ann instead of Bob.

trait Fili {
  def kili(edo: Bob): Int
}
// <<<< Before 
// >>>> After
trait Fili {
  def kili(edo: Ann): Int
}

Comments

Some "proverbs" of engineering, to which this rule help, are those of programming against an interface, not an implementation; as well as the old minimum access.

Examples

One circumstance in which this often happens is in the cats library, and projects that use its type-classes (which are just traits of a higuer kind). It often happens that an implicit parameter is declared to require a Monad[F] parameter, when only the map method (from the Functor trait) is used.

Here are some examples from the same set of related libraries:

• Massively too Strict a Constraint http4s/http4s#2565
• reduce constraint of foldMapM from Monad to Applicative typelevel/cats#2854
• Delete unnecessary restriction on biFlatMap typelevel/cats#2837

[rorygraves]

Great idea

[Daenyth]

This will need some controls: An example being cats-effect Bracket vs Sync. You might be using the "lower" interface because of the additional laws, which aren't represented in code.