overloaded '==' in case class doesn't compile

[ryan-williams]

tricky situation I just ran in to:

trait A

trait B[C <: B[C]] {
  def ==(o: C)(implicit a: A): Boolean = ???
}

trait D[C <: B[C]]

case class E[C <: B[C]](c: C) extends D[C]

gives compile error:

 error: could not find implicit value for parameter a: A
       case class E[C <: B[C]](c: C) extends D[C]
                  ^

seems like a generated method in the case class E collides with the overloaded B.== which requires an implicit A.

maybe the answer is to just not overload == in this way, but the error msg is not very clear about the issue so I wanted to document it here.

[Jasper-M]

I think you shouldn't overload == at all.
The error probably comes from the autogenerated equals method. I would imagine that it contains something like this.c == that.c which now selects your overloaded method instead.

[Jasper-M]

This one is even more fun:

class A { def ==(a: A) = "lol" }
case class B(a: A)
B(new A) == B(new A)

It blows up at runtime with a ClassCastException.
I would say this one even comes close to being an actual bug.

[maborg]

I have found something very similar and posted on StackOverflow and there is not considered a bug, or at least they point me to avoid to override ==. It's correct?

[Jasper-M]

It's impossible to override ==, because it is a final def in class Any. And it's also a very bad idea to overload it.
As to why case class B(a: A) even compiles while B(new A) == B(new A) throws a ClassCastException is a bit of a mystery to me. Somehow the generated equals method survives the typer phase, but after the erasure phase I can see that the compiler adds a call to unbox the result of this.a == that.a, which leads to the ClassCastException. However when I manually write the code that gets generated for equals that doesn't happen.

You shouldn't overload ==, but something strange is happening here either way. I feel like at some point the compiler should give an error or at least a warning before inserting ClassCastExceptions.

[soronpo]

@Jasper-M please reopen this issue. Ability to override == is important for DSLs. I use it in my library and use an ugly workaround for this issue.