Question

Because traits with representation types are self-referential, declaring that a variable holds an instance of that trait is a little difficult. In this example I simply declare that a variable holds an instance of the trait, declare that a function takes and returns and instance of that trait, and call that function with the variable:

trait Foo[+A <: Foo[A]]
case class Bar() extends Foo[Bar]
case class Grill() extends Foo[Grill]

// Store a generic instance of Foo
val b: Foo[_] = if(true) {
  Bar()
} else {
  Grill()
}

// Declare a function that take any Foo and returns a Foo of the same type
// that "in" has in the calling context
def echoFoo[A <: Foo[A]](in: A): A = in

// Call said function
val echo = echoFoo(b)

It fails with the error:

inferred type arguments [this.Foo[_$1]] do not conform to method 
echoFoo's type parameter bounds [A <: this.Foo[A]]
val echo = echoFoo(b)
           ^

Now, this makes sense because [_] is like Any (in ways I don’t fully understand). What it probably wants is something like Foo[Foo[_]], so that the type parameter conforms to the bounds of A <: Foo[A]. But now there’s an inner Foo that has a non-conforming type parameter, suggesting that the solution is something like Foo[Foo[Foo[Foo[..., which is clearly not correct.

So my question can probably be distilled down to: What is the Scala syntax for “This variable holds any legal Foo“?

Answer 1

Self-referential type parameters like this are a bit problematic, because they’re not sound. For example, it’s possible to define a type like the following:

case class BeerGarden extends Foo[Grill]

As you can see, the A <: Foo[A] bound isn’t sufficiently tight. What I prefer in situations like this is to use the cake pattern, and abstract type members:

trait FooModule {
  type Foo <: FooLike

  def apply(): Foo

  trait FooLike {
    def echo: Foo
  }
}

Now you can use the Foo type recursively and safely:

object Foos {
  def echo(foo: FooModule#Foo) = foo.echo
}

Obviously, this isn’t an ideal solution to all the problems you might want to solve with such types, but the important observation is that FooLike is an extensible trait, so you can always continue to refine FooLike to add the members that you need, without violating the bound that the type member is intended to enforce. I’ve found that in every real-world case where the set of types I want to represent is not closed, this is about the best that one can do. The important thing to see is that FooModule abstracts over both the type and the instance constructor, while enforcing the “self-type.” You can’t abstract over one without abstracting over the other.

Some additional information on this sort of thing (and a bit of a record of my own early struggles with recursive types) is available here:

https://issues.scala-lang.org/browse/SI-2385