Calling n-ary case class constructor

I have a case class defined as follows

case class IntersectionType(U: Type*) extends Type { 
   ...
   override def foo:Type = {
      IntersectionType.apply(U.distinct)  // compiler complains here
  }

What is the correct way to call passing U.distinct not Seq(U.distinct) as the value of U ?

I found the : _* syntax. So now I’ve tried the following in several places in my code.

IntersectionType(U.distinct : _*)

now the compiler gives me the following error, without giving me a line number where the error occurs.

scalac: Error: Star pattern must correspond with varargs or unapplySeq

Can someone help me understand this syntax? Am I using : _* incorrectly ?

For example is this intended to work?

IntersectionType(U.flatMap {
            case IntersectionType(xs@_*) => xs
            case x => Seq(x)
          } : _*)

I’m trying to play around with this some, and I’m wondering what is the type of U?

U is the argument of the case class constructor. Here is a fictious piece of code
which I think shows the problem.

sealed abstract class Type { ...}

case class AtomicType extends Type {}

case class IntersectionType(U: Type*) extends Type {

  def rmRedundantAnds = {
    val ands = U.find {
          case IntersectionType(_) => true
          case _ => false
    }
    if (ands.isEmpty)
      this
    else {
      IntersectionType(U.flatMap {
            case IntersectionType(xs @ _*) => xs
            case x => Seq(x)
          } : _*)
    }
 }
}

That compiles just fine.
Are you sure the error is real? Or maybe is just another false positive from Intellij.

BTW, personal opinion, having a variable named U is very confusing.
Second, I would just use List or whatever type instead of varargs internally and maybe just provide an overload apply on Type or something for users.

What’s your motivation for avoiding the varargs BalmungSan?

Yes it seems to be a problem of compilation. IntelliJ doesn’t complain at all.
The file is 650 lines long and somewhere in the file compiler is giving the error.

scalac: Error: Star pattern must correspond with varargs or unapplySeq
scala.reflect.internal.Types$TypeError: Star pattern must correspond with varargs or unapplySeq

but it doesn’t say which line number. I think that’s probably a bug in the error reporter within the compiler, that it fails to issue a line number.

I can reproduce this in Scastie.

I get a very similar error again without a line number.

scala.reflect.internal.Types$TypeError: Star pattern must correspond with varargs or unapplySeq

According to Scastie, seems like I get the same error in Scala 2.13

Yea, I think capital U is a confusing name. I got the code from somewhere else. At first the capital letters looked like type parameters. I’ve changed some of them, but not all of them yet.

Good suggestion about eliminating the capital letters.

1 Like

It is quite hard to debug 600 lines of code, but after some simple experiments (mostly putting parenthesis around some operations) I would say that the error is not the : _* but rather on one of the pattern matches.
I would recommend you to try to minimize it. Worst / best case it is a bug in the compiler.

I was trying to split the code between files to find out which file the compiler complains about.
But I haven’t figured out how to build an ADT which spans files. Still studying your previous message about that.

The first and most important one is that a varargs returns a Seq, which as we have discussed here before (and many times in the gitter channel). I simply do not like them, I came to realize that for some people that is a good abstraction, so I no longer tell people they are “bad”, but I still think that a Seq has to be treated with care and I still avoid it in my code (and since this time I was clear it was my opinion).

Secondly, because I find it very tedious to use the : _* all over the place.
So, that is why I would use a List (or Vector or ArraySeq) internally and just provide an alternative apply that accepts a varargs so users can call it.

Every programmer is happy to find a compiler bug. :stuck_out_tongue_winking_eye:

1 Like

I think I found the bug.