Add unapply methods that return an Option for compatibility?

[smarter]

Here's an interesting problem minmized from https://github.com/lampepfl/dotty/blob/master/compiler/src/dotty/tools/dotc/repl/ammonite/Protocol.scala that causes dotty-compiler-bootstrapped/repl to go into an infinite loop:

class Foo
case class Bar(x: Int) extends Foo

object Bar {
  def unapply(foo: Foo): Option[Int] = foo match {
    case foo: Bar =>
      unapply(foo)
  }
}

With scalac, the unapply call goes to the generated def unapply(x$1: Bar): Option[Int] , but with dotty no such method exist, instead we only generate a def unapply(x$1: Bar): Bar, so the previously perfectly correct code becomes an infinite loop!

I think we can fix this by always generating an unapply method that returns an Option, even if we don't use it.

[odersky]

Great that you got to the bottom of this! I think you meant:

case foo: Bar =>
  unapply(foo)

It turns out that neither this method nor the original method in Ammonite is needed. They just duplicate the typecheck that the compiler does anyway. One can and should delete them.

I am not very keen about generating a new method. It's ugly and will get us into overloading troubles. On the other hand, it certainly is a serious incompatibility with Scala 2.

[smarter]

I think you meant: ...

Yes, edited.

It turns out that neither this method nor the original method in Ammonite is needed. They just duplicate the typecheck that the compiler does anyway. One can and should delete them.

I tried to delete the unapply(ti: TermAction) in https://github.com/lampepfl/dotty/blob/master/compiler/src/dotty/tools/dotc/repl/ammonite/Protocol.scala and got an ambigous overload error because of the other unapply (unapply(ti: TermInfo)), removing that one breaks everything. Did you find a way to get it to compile?

[odersky]

I see. Well, in that case just inline TermState.unapply(ts) to Some(....)? I still think it's a corner case which should not force us to use an ugly compilation scheme.

[OlivierBlanvillain]

Introducing an unapplyWorkaround method with the same signature that the scalac generated one does the trick.

[smarter]

@olafurpg Could you try to get some statistics on how often Scala projects explicitly use unapply ? (That is, unapply was written by the user and not generated by pattern-matching).