Strict equality CanEqual derivation fails for classes in which type argument is not used for equality

[SimY4]

Compiler version

Scala 3.1.1

Minimized code

import scala.language.strictEquality

case class MyClass[A](value: String)(val a: A) derives CanEqual

class Something {}

val a = MyClass[Something]("some")(new Something())
val b = MyClass[Something]("some")(new Something())

println(a == b)

Output

Values of types Playground.MyClass[Playground.Something] and Playground.MyClass[Playground.Something] cannot be compared with == or !=.
I found:

    Playground.MyClass.derived$CanEqual[Playground.Something, Playground.Something](
      /* missing */summon[CanEqual[Playground.Something, Playground.Something]]
    )

But no implicit values were found that match type CanEqual[Playground.Something, Playground.Something].

Expectation

Something is not part of case class universal equality check so it shouldn't be part of multiversal equality constraint either

[spamegg1]

I cannot reproduce it:

 ➜ scala
Welcome to Scala 3.1.1 (17.0.1, Java OpenJDK 64-Bit Server VM).
Type in expressions for evaluation. Or try :help.
                                                                                                                                       
scala> case class MyClass[A](value: String)(val a: A) derives CanEqual
// defined case class MyClass
                                                                                                                                       
scala> class Something {}
// defined class Something
                                                                                                                                       
scala> val a = MyClass[Something]("some")(new Something())
val a: MyClass[Something] = MyClass(some)
                                                                                                                                       
scala> val b = MyClass[Something]("some")(new Something())
val b: MyClass[Something] = MyClass(some)
                                                                                                                                       
scala> println(a == b)
true

[SimY4]

@spameggo you need to enable strict quality via:

import scala.language.strictEquality

[nicolasstucki]

It seems that the code above is correctly complaining as there is no instance of CanEqual[Something, Something] in scope. This implicit is required because derives CanEqual generates the following given instance

given derived$CanEqual[L, R](implicit x$0: CanEqual[L, R]): CanEqual[MyClass[L], MyClass[R]] = CanEqual.derived

Note that under strict equality the comparison new Something == new Something will also not work without the CanEqual[Something, Something]. To make this code compile you can add

given CanEqual[Something, Something] = CanEqual.derived

or derive it on Somthing

class Something derives CanEqual {}

[nicolasstucki]

@odersky should derive generate givens with implicit parameters or using parameters?

- given derived$CanEqual[L, R](implicit x$0: CanEqual[L, R]): CanEqual[MyClass[L], MyClass[R]] = CanEqual.derived
+ given derived$CanEqual[L, R](using x$0: CanEqual[L, R]): CanEqual[MyClass[L], MyClass[R]] = CanEqual.derived

I would have expected a using.

[SimY4]

@nicolasstucki @odersky I would argue that my understanding of strict equality feature was merely about making equality checks safer at compiler time, not to actually change the semantics of case class equality.

[SimY4]

To be fair, I was hoping that CanEqual for case classes would simply delegate to case class generated equality.

[bishabosha]

To be fair, I was hoping that CanEqual for case classes would simply delegate to case class generated equality.

It does, CanEqual has no methods to call, the == operation still delegates to equals, it just checks at compiletime if there exists the correct CanEqual in implicit scope

[SimY4]

Sorry for the perseverance, but what's the outcome here? I disagree that the feature works as expected for this case and CanEqual derivation can be improved. I'm happy to be proven wrong if you point me to the documentation explaining why

[bishabosha]

Something is not part of case class universal equality check so it shouldn't be part of multiversal equality constraint either

ok so in this case you would want a feature change so that CanEqual derivation can analyse the equals method - this is hard in general, but making it specialised for this one use case of "if user does not define custom equals, and generic type parameter does not appear in primary constructor of case class" could be possible