Are all instances provided by the Cats module valid?

[Iltotore]

Asking to @gvolpe since my knowledge about Cats is limited.

The Cats module provides several instances for refined types based on the instance of their inner (raw) type:

inline given [A, B](using inline ev: Semigroup[A]): Semigroup[A :| B] = ev.asInstanceOf[Semigroup[A :| B]]

but is the above instance valid? For example, if I have a Semigroup[Int] that combine x and y by doing x-y, it shouldn't work for Int :| Greater[0] because the combination result can be negative right?

[gvolpe]

Yes, that's a good point. Adding validation to derived typeclass instances may be tricky, we'd need some type-level machinery. You can see what Refined does here: https://github.com/fthomas/refined/blob/master/modules/cats/shared/src/main/scala/eu/timepit/refined/cats/package.scala#L105

There are a lot of unsafe refinements, not sure if this is even possible.

[Iltotore]

It seems totally possible but I am a bit skeptical: the instances (like CommutativeSemigroup[A Refined Positive]) seems to add a very specific and custom semigroup. I don't get the need for it.

For example, if I understand their code correctly,

val x: Int Refined Positive = ???
val y: Int Refined Positive = ???

x |+| y

would result in (x |+| y) & Int.MaxValue. This will effectively keep the result positive, respecting the Positive constraint but this logic is IMHO too specific/custom/non-standard to be really intuitive.

For example, given a CommutativeSemigroup[Int] with a |+| b<=> -(a + b):

val a: Int = 1
val b: Int = 2

a |+| b //-3


val x: Int Refined Positive = 1
val y: Int Refined Positive = 2

x |+| y //2147483645 ?!

What makes this CommutativeSemigroup[A Refined Positive] more natural or intuitive than abs(a |+| b) for example?

I think we should only keep the instances that have an obvious, natural behaviour compared to their "unrefined" counterpart like Eq for example which should have the exact same behaviour for A and A :| C.

And let the users define their own instances when they are non obvious.

[gvolpe]

I think we should only keep the instances that have an obvious, natural behaviour compared to their "unrefined" counterpart like Eq for example which should have the exact same behaviour for A and A :| C.

Seems like a sensitive decision. Another option would be to place these instances under io.github.iltotore.iron.cats.alley.* or so (see https://github.com/typelevel/cats/tree/main/alleycats-core).

[Iltotore]

Seems like a sensitive decision.

Don't worry, I will not instantly remove these instances 😅 . This is just a proposal at the moment.

Another option would be to place these instances under io.github.iltotore.iron.cats.alley.* or so

Seems like a good middle ground but I am still wondering if these instances are actually "useful" enough to be kept. Also unlike AlleyCats, the problem is not that the provided instances have "caveats" but have an arbitrary behaviour which is not always obvious.

I now understand why a CommutativeSemigroup[Int :| Positive] is useful but in its actual state, Iron Cats provides this instance for all refined types (if their inner type has a CommutativeSemigroup) !

inline given [A, B](using inline ev: CommutativeSemigroup[A]): CommutativeSemigroup[A :| B] = ev.asInstanceOf[CommutativeSemigroup[A :| B]]

this current instance is not ok:

given CommutativeSemigroup[Int] = ??? // -(a + b)

val a: Int :| Positive = 5
val b: Int :| Positive = 4

val result: Int :| Positive = a |+| b //-9 but it's actually negative!

So here is my proposal:

• Remove those "invalid" instances (like the one mentioned above). Actually, even Refined does not have those (AFAIK)!
• Let some instances for specific constraints (e.g CommutativeSemigroup with Positive like in Refined)
• Let the "always valid" instances like Eq, Ord etc...

[gvolpe]

Sounds good to me 👍🏽