No warning/error when matching unrelated object types

[olofwalker]

Minimized code

Dotty 0.27-RC1

object Main:

  abstract class RecoveryCompleted
  case object RecoveryCompleted extends RecoveryCompleted
  
  abstract class TypedRecoveryCompleted 
  case object TypedRecoveryCompleted extends TypedRecoveryCompleted

  TypedRecoveryCompleted match {
    case RecoveryCompleted => println("Recovery completed")
    case TypedRecoveryCompleted => println("Typed recovery completed")
  }

Output

Nothing

Expectation

Something like:

pattern type is incompatible with expected type;
 found   : ammonite.$sess.cmd5.RecoveryCompleted.type
 required: ammonite.$sess.cmd7.TypedRecoveryCompleted.type
    case RecoveryCompleted => println("Recovery completed")

[liufengyun]

This seems to be the correct behavior. See the following example:

class Error {
  abstract class RecoveryCompleted
  case object RecoveryCompleted extends RecoveryCompleted {
    override def equals(that: Any): Boolean = that == TypedRecoveryCompleted
  }

  abstract class TypedRecoveryCompleted
  case object TypedRecoveryCompleted extends TypedRecoveryCompleted


  TypedRecoveryCompleted match {
    case RecoveryCompleted => println("Recovery completed")
    case TypedRecoveryCompleted => println("Typed recovery completed")
  }
}

object Test {
  def main(args: Array[String]): Unit = new Error
}

The first branch matches.

[liufengyun]

Related: #3200 scala/bug#1503

[olofwalker]

@liufengyun

This fails in 2.13, I just assumed this would also fail in Dotty.

pattern type is incompatible with expected type
[error]  found   : Error.this.RecoveryCompleted.type
[error]  required: Error.this.TypedRecoveryCompleted.type

The context for this is that I never got a RecoveryCompleted signal to fire in an Akka persistent actor, there are two of those classes, one for classic actors and one for typed, and I had imported and used the wrong one.

[liufengyun]

@olofwalker Thanks for clarifying the context. It's a difference between Scala 2 and Scala 3.

Maybe Scala 3 should be more conservative here to prevent such mistakes.

[olofwalker]

@liufengyun I think I would have been helped by a warning, its a bit like Scala 2, you unknowingly import an implicit, and all of a sudden things work differently.

[smarter]

We can't just copy what 2.13 is doing here as demonstrated by Fengyun's example in #9740 (comment), scalac wrongly emits an error even though this code is correct. We would have to check if equals in RecoveryCompleted is compiler-generated first

[liufengyun]

We can't just copy what 2.13 is doing here as demonstrated by Fengyun's example in #9740 (comment), scalac wrongly emits an error even though this code is correct. We would have to check if equals in RecoveryCompleted is compiler-generated first

It is incomplete, but it seems sound/safe to reject the code. The additional expressiveness seems to be not useful in practice, and usually implies something goes wrong.

[smarter]

It's safe but it might be annoying to someone :). But I think if we only emit the warning if scrutinee.is(Case) && scrutineeEqualsMethod.is(Synthetic) then it's fine and catch the cases we're interested in.

[smarter]

Oops actually we want to check the symbol of the case, not the symbol of the scrutinee.

[liufengyun]

After reflection, I think the correct thing to do is either (1) disallow all such cases; or (2) allow all such cases. Anything in the middle (like checking whether the member equals is overridden) only complicates the protocol.

Disallowing all such usage would align with Scala 2 and prevent accidental errors in practice. It's safe and sound -- incompleteness is fine, as static checks are all incomplete for good reasons.

Are there valid use cases that justify allowing such usage?

[dwijnand]

I agree. Can always make it more complicated if that proves too annoying - which hasn't appeared to be the case for Scala 2 users so far.

The argument around Fengyun's example to me seems to revolve around the fact that any scrutinee type (e.g. TypedRecoveryCompleted.type) is a subtype of Any and that any class can redefine its equals to be true for that singleton. But (1) that's unlawful for equals (though the type system can't rely on that) and (2) (more importantly) making that concession undermines the reachability checking/safety of all matches.