How to handle overriden equals with Matchable?

[joschua-fink]

Minimized example

When overriding the equals method, this is a common pattern in Scala 2:

trait Foo {
  override def equals(obj: Any): Boolean = obj match {
    case foo: Foo =>
      ???
    case _ =>
      false
  }
}

Output

Using Scala 3.0.0-M3 with -source 3.1 I get the following warning:

[warn] 14 |      case foo: Foo =>
[warn]    |                ^^^
[warn]    |                pattern selector should be an instance of Matchable,
[warn]    |                but it has unmatchable type Any instead

Question

What is the alternative for this pattern? Since according to the documentation isInstanceOf may also be moved into Matchable, which will make the following workaround (which is basically the way it's done in Java) inviable as well:

trait Bar {
  override def equals(obj: Any): Boolean = {
    if obj.isInstanceOf[Bar] then
      val bar = obj.asInstanceOf[Bar]
      ???
    else
      false
  }
}

[sjrd]

Well, that is a very good question. I have no idea what to do. This could be very damaging to the Matchable idea.

In a new world, I'd say we should change the type of obj to be Matchable. But doing that will break all existing code, so that's not viable.

[SethTisue]

I've resorted to obj.asInstanceOf[Matchable] match ...

[nafg]

This might be an argument for the original approach, where instead of making Any less concrete and adding a more concrete subtype (Matchable), we leave Any with its current semantics and add a more abstract type over it (previously called Top, though I hope it would get a better name).

[odersky]

Yes, you'll need the asInstanceOf in this case. The compiler does the same in the code it synthesizes for case classes:

trait Foo {
  override def equals(obj: Any): Boolean = obj.asInstanceOf[Matchable] match {
    case foo: Foo =>
      ???
    case _ =>
      false
  }
}

[nafg]

Another option would be to change the official signature of equals to take a Matchable, but to special-case so that is it's defined with Any it accepts it with a warning. It would have the same erasure anyway no?

…

On Sun, Dec 20, 2020, 1:47 PM odersky ***@***.***> wrote: Yes, you'll need the asInstanceOf in this case. The compiler does the same in the code it synthesizes for case classes. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#10855 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAYAUE53523K7ZFDNOV6G3SVZBD7ANCNFSM4VBF3PCQ> .

[sjrd]

Yes, you'll need the asInstanceOf in this case. The compiler does the same in the code it synthesizes for case classes:

That is really annoying, though. It sets a precedent of requiring users to use an asInstanceOf in well-typed, idiomatic code.

[odersky]

No, the code is not well typed. Universal equals is impossible to define in a safe way once you have the Matchable restriction. So it's only natural that we require that this is acknowledged explicitly.

One way out is to drop Matchable and decree that universal equals is cast in stone. The other way is to get rid (over time) of universal equals. You know where my preference lies...

[dcsobral]

Doing case foo: Foo => on equality would break opaque types. equals could require Any & Matchable, in which case opaque types could not be compared with equals at all, == and != could special case opaque types, perhaps.

[rjolly]

We could pre-overload equals in Matchable like so:

trait Matchable {
  def equals(obj: Any) = {
    if obj.isInstanceOf[Matchable] then equals(obj.asInstanceOf[Matchable])
    else false
  }
  def equals(obj: Matchable): Boolean
}

[LPTK]

@dcsobral Any & Matchable reduces to Matchable.

@rjolly Maybe a good stop-gap measure, though that would break virtually every code base where equals is defined. But it's an improvement over requiring everyone to switch to asInstanceOf.

Ultimately, @nafg's suggestion may be the best, moving forward. It's looking more and more like adopting parametricity needs a big, clean break from existing practices, as it does not seem possible to meaningfully migrate to parametricity incrementally.

The current Matchable approach, which keeps equals and hashCode in every type, falls short. While it does prevent some unsound opaque type matches, I worry that it would just add noise and get in the way of a future big, clean break for parametricity. Would equals and hashCode eventually be removed from Any, or would yet another top type be introduced, making the Any/Matchable duality mostly redundant?

[Jasper-M]

IMHO this is an indication that this type of change is something that requires a lot of time and experimentation to get right. And will probably also require a pretty sweeping change in how things are done in Scala (e.g. a much more typeclassy interface over all the Java stuff) in order for this to be more than just some annoying thing that most people just asInstanceOf into oblivion and get on with their lives.

And both of those things seem to be way out of scope at the moment.

[rjolly]

I don't think people are overriding equals that often. Any sane Scala developer should avoid fiddling with that pre-parametric Java stuff. Actually in years of Scala development I had never noticed that the argument type is Any in equals and not Object aka AnyRef as in Java. What we should have (even maybe backported to Scala 2) is actually:

trait AnyRef {
  def equals(obj: AnyRef) = {
    if obj.isInstanceOf[AnyRef] then equals(obj.asInstanceOf[AnyRef])
    else false
  }
  def equals(obj: AnyRef): Boolean
}

as I suppose equals in AnyVal is special-cased anyway.

[sjrd]

Any sane Scala developer should avoid fiddling with that pre-parametric Java stuff.

I consider myself a sane Scala developer, and I very often have to override equals and hashCode to implement structural equality on immutable structures that are not case classes.