dotty 0.24 don't use pattern binding type info when infering type

[ohze]

Minimized code

object Test {
  def fishForSpecificMessage[T](f: PartialFunction[Any, T]): T = ???

  val s: String = fishForSpecificMessage {
    case msg@"fishForMe" => msg
  }
}

Output (dotty 0.24.0-RC1)

[info] Compiling 1 Scala source to /example/target/scala-0.24/classes ...
[error] -- [E007] Type Mismatch Error: /example/src/main/scala/Test.scala::5:28 
[error] 5 |    case msg@"fishForMe" => msg
[error]   |                            ^^^
[error]   |                            Found:    (msg : Any)
[error]   |                            Required: String

Expectation

Compile successfully as in dotty 0.23.0 and scala 2
Note: Also fail with dotty 0.25.0-bin-20200607-345c8bc-NIGHTLY

[bishabosha]

this appears to be by specification, and that the old behaviour was incorrect
e.g. in tests/neg/i3200:

object Test {
  case object Bob { override def equals(other: Any) = true }
  def main(args: Array[String]): Unit = {
    val m : Bob.type = (5: Any) match { case x @ Bob => x }  // error
  }
}

Here, val m : Bob.type = (5: Any) match { case x @ Bob => x } fails because x is type Any

[LPTK]

@bishabosha this seems to contradict @sstucki's approach to handling custom extractors. IIRC, the pattern you use may affect the type of the pattern variable bound to it with @. Maybe @sstucki can confirm?

[smarter]

IIRC, the pattern you use may affect the type of the pattern variable bound to it with @.

Not sure what you're referring to exactly, but as seen with the example posted above, you cannot do this in general because equals can be overriden to return true for a value of a different type. It would be safe to do it for { case foo @ "somestring" } because of the way String#equals behave but that would require special-casing it.

[giabao]

So this issue is closed because the behaviour IS by specification and dotty WILL NOT check any special case, eg for String type, when infering type of pattern binding variables?

[bishabosha]

@LPTK currently it is a special case to use the scrutinee type only when the pattern is a stable identifier or a literal.
@smarter Which literal trees could have types that override equals?
@giabao this could be reopened as a feature request to allow literal types to be propagated when we know equals is safe

[smarter]

Which literal trees could have types that override equals?

http://dotty.epfl.ch/docs/reference/changed-features/numeric-literals.html maybe

[LPTK]

@smarter @bishabosha ah right, I had read the issue too fast. The one thing I remembered was when matching by type (or using an extractor to do so), not when matching by instance. It is a little annoying that the two seem similar but have different semantics. It feels like a cleaner specification of instance matching would be in terms of eq, although it would be less flexible.

[smarter]

It feels like a cleaner specification of instance matching would be in terms of eq, although it would be less flexible.

I think that experiment was tried in scalac and abandoned because it broke too much code.