x @ _* bound variables are now scala.Seq; name-based pattern matching changes to enable this

[lrytz]

With name-based pattern matching, unapplySeq can return any type that
has an isEmpty and get methods. The object returned by get needs
to have apply, length or lengthCompare and drop methods.

This PR changes the type of x @ _* bound variables to scala.Seq. To support
that change, the object returned by unapplySeq.get is converted by
calling .toSeq or drop(n).

This means there are two changes in the interface for name-based pattern
matching:

• the object needs to define a toSeq method
• the drop method needs to return a scala.Seq

The unapplySeq method defined in collection.SeqFactory now returns
a value class wrapper that delegates to the collection. toSeq no
longer exposes mutable collections.

Array.unapplySeq uses a similar value class wrapper.

Fixes scala/bug#11040

[lrytz]

@szeiger this should be ready, I didn't run the full test suite locally though.

[SethTisue]

tentatively marked as "prio:blocker"... at least, deciding whether it goes in is a blocker

[retronym]

This looks like a sensible way out of this corner.

[lrytz]

cc @odersky in case you'd like to share your opinion on this

[viktorklang]

Seems we could avoid creating both a Range + a List + another List with List.tabulate(n)(codegen index seqTree(binder, forceImmutable = false)) ?

[lrytz]

Thanks, pushed that suggestion.

[SethTisue]

squashed. I'll merge as soon as CI likes it

[liufengyun]

I'm looking at supporting this in Dotty. I have a little question regarding the specification for name-based unapplySeq. Given the following result type from get:

  class Data {
    def lengthCompare(len: Int): Int
    def apply(i: Int): T1 = a(i)
    def drop(n: Int): scala.Seq[T2]
    def toSeq: scala.Seq[T3]
  }

My question: does the specification imposes that T1, T2 and T3 are the same type, or the element type is going to be lub(T1, T2, T3)? I prefer the former, which is simple and doesn't seem to harm expressiveness.

Ping @lrytz

[allanrenucci]

This looks like a bug in scalac:

object Array2 {
  def unapplySeq[T](x: Array[T]): UnapplySeqWrapper[T] = new UnapplySeqWrapper(x)

  class UnapplySeqWrapper[T](a: Array[T]) {
    def isEmpty: Boolean = false
    def get: UnapplySeqWrapper[T] = this
    def lengthCompare(len: Int): Int = ???
    def apply(i: Int): Int = ???
    def drop(n: Int): scala.Seq[String] = ???
    def toSeq: scala.Seq[Double] = ???
  }
}

class Test {
  import Array2._
  def test(xs: Array[Int]) = xs match {
    case Array2(1, 2, ys @ _*) => ys
  }
}

> scalac Test.scala
Test.scala:16: error during expansion of this match (this is a scalac bug).
The underlying error was: type mismatch;
  found   : Seq[String]
  required: Seq[Int]
   def test(xs: Array[Int]) = xs match {
                                 ^
 one error found

[liufengyun]

Another possibility is not to require T1, T2, T3 to be the same, but designate one of them to be the element type, and the other two types should conform to the element type.

The motivation for this spec is that it seems to simplify implementation scala/scala3#5078 .

[szeiger]

Do we need a special relationship between these types at all? The shape of the pattern determines statically which methods are called and therefore which one of T1, T2 and T3 is the actual element type.

[lrytz]

The implementation as of this PR takes the apply method's return type T as element type (see here), and requires the result of toSeq and drop to conform to Seq[T] (see here). So the example by @allanrenucci fails as expected.

I'm happy to discuss other / better ways to skin that cat, of course.

[allanrenucci]

I'd like to point out that the scalac error message says: "error during expansion of this match (this is a scalac bug)"

So if it is expected, I would not report it as a scalac bug 😄

[lrytz]

Yes, you're right about the message being confusing :-) See scala/bug#11102

[liufengyun]

Thanks a lot @lrytz , making the result type of apply as element type works well, I've made it explicit in the Dotty spec.

[liufengyun]

@szeiger It matters for Dotty (I'm not sure about Scalac) as semantic translation of patmat happens after type checking. The typer just assumes an element type. If the types T1, T2 and T3 are not constrained, there may be run-time exceptions.