Provide CanEqual for Option (Option == None), Throwables, and other

[strelec]

Minimized code

x match {
  case Some(value) =>
  case None =>
}

Output

[error] 129 |					case None =>
[error]     |					     ^^^^
[error]     |					     Values of types object None and Option[T] cannot be compared with == or !=.
[error]     |					     I found:
[error]     |
[error]     |					         CanEqual.canEqualOptions[T, U](/* missing */summon[CanEqual[T, U]])
[error]     |
[error]     |					     But no implicit values were found that match type CanEqual[T, U].

Expectation

CanEqual instance should come already defined for at the very least, the standard library. You have to strike a balance between versatility and usability.

As it is currently, -language:strictEquality is too cautious to be useful.

[odersky]

The problem is that the CanEqual instance would logically have to be in the companion object of Option. But we cannot touch the standard library for the time being, since we want to use 2.13.

At some point we need to decide that we will ship a Scala 3 specific standard library, and in that case CanEqual instances would be provided. Until then, I agree that -language:strictEquality is not useful and should be avoided.

[nicolasstucki]

We may be able to synthesize that instance while we still use the 2.13 library

[odersky]

Synthesizing looks very hard when we need to put the CanEqual in Option, where it belongs. Yes, we could shadow Option, but it's a maintainability nightmare to track any changes in the 2.13 version of Option from then on.

Maybe we should deprecate strictEquality instead. It was really meant only as a demonstrator to show that the system would support that. But given the present state of libraries it's not useful, so we should discourage people from trying to make it work.

[strelec]

I agree with @odersky here about deprecating strictEquality. And that is okay, things are experimental for a reason.

Being a scala user for almost 10 years now, it is the first feature I did not really like. So much boilerplate just to get a bit better type safety. And it feels I was fighting it the whole way. I also do not like it generates a method with a bunch of lazy val fields the JVM bytecode (I thought it was erased at compile time).

I think that the solution that outputs a compiler warning (or heck, even an error) when two things cannot possibly be equal would be a step gap solution that could serve us for years.

Eventually we will find a proper solution that will still be playing nicely with the JVM. But that will require some serious out out the box idea, so let's not commit to a solution in question just yet.

[kevin-lee]

@strelec Do you still have this problem? Are you using Scala 3.0.x?
It should be fixed by #12419 and #13265 in Scala 3.1.0 and higher.

[ckipp01]

I'm unable to reproduce this with

//> using scala 3.nightly
//> using options -Wunused:all -language:strictEquality

object Test:
  val x: Option[String] = None
  x match {
    case Some(value) =>
    case None        =>
  }

Can this be closed, or am I missing something from your original case @strelec