Abstract types versus type parameters

In what situations should abstract types be preferred over type parameters?

To add to my previous answer on Abstract type vs. parameters, you have also the JESSE EICHAR's recent blog post (2010, May 3rd) highlighting some key differences:

trait C1[A] {
  def get : A
  def doit(a:A):A
}
trait C2 {
  type A
  def get : A
  def doit(a:A):A
}

In C2 case, the parameter is "buried" (as an internal abstract type).
(except, as retronym puts it, it is not actually buried, see below)

Whereas with generic type, the parameter is explicitly mentioned, helping other expressions to know what type they are supposed to used

---

So (C1: parameter):

//compiles
def p(c:C1[Int]) = c.doit(c.get)

It compiles, but you expose explicitly the 'A' type you want to use.

And (C2: Abstract type):

// doesn't compile
def p2(c:C2) = c.doit(c.get)
<console>:6: error: illegal dependent method type
       def p2(c:C2) = c.doit(c.get)
              ^

It doesn't compile because 'A' is never mentioned in p2 definition, so doit doesn't know at compile type what it is supposed to return.

---

When using abstract type and wanting to avoid any "type leaking" to the interface (i.e. wanting to expose what 'A' actually is), you could specify a very generic type as a return for p2:

// compiles because the internals of C2 does not leak out
def p(c:C2):Unit = c.doit(c.get)

Or you could "fix" that type directly in the doit function:
def doit(a:A):Int instead of def doit(a:A):A, which means:
def p2(c:C2) = c.doit(c.get) will compile (even if p2 doesn't mention any return type)

---

Finally (retronym's comment) you can specify A either explicitly by refining C2 abstract parameter:

scala> def p2(c:C2 { type A = Int }): Int = c.doit(c.get)
p2: (c: C2{type A = Int})Int

Or by adding a type parameter (and refining C2 abstract type with it!)

scala> def p2[X](c:C2 { type A = X }): X = c.doit(c.get)
p2: [X](c: C2{type A = X})X

---

So abstract are recommended:

• When you want to hide a the exact definition of a type member from client code, use abstract type like in C2 (but be wary of the definition of function using C2)
• When you want to override the type covariantly in subclasses of C2, use abstract type (with bounded type abstraction)
• When you want to mix in definitions of those C2 types via traits, use abstract type (you won't have 'A' to deal with when mixing C2 with your class: you mix only C2)

For the rest, where simple type instantiation is need, use Parameters.
(if you know that no extension will be needed, but you still have to handle several types: that is what Parameter types are for)

---

retronym adds:

The main differences are

• variance: C2 can only be invariant in A,
• the way that type members can be selectively overriden in a subtype (whereas type parameters must be redeclared and passed to the supertype)

(as illustrating here:

trait T1 {
  type t
  val v: t
}
trait T2 extends T1 {
  type t <: SomeType1
}
trait T3 extends T2 {
  type t <: SomeType2  // where SomeType2 <: SomeType1
}
class C extends T3 {
  type t = Concrete    // where Concrete <: SomeType2
  val v = new Concrete(...)
}

---

Dmytro Mitin adds in 2023 in the comments:

variance: C2 can only be invariant in A

This is not completely true.
Just variance of C1 can be declared both at the definition site and at a call site, while variance of C2 can be declared only at call site (as for type parameters in Java)
See "Scala: Abstract types vs generics"

"the way that type members can be selectively overridden in a subtype"

This is not a difference either.

trait T1[t] 
trait T2[t <: SomeType1] extends T1[t] 
trait T3[t <: SomeType2] extends T2[t] 
class C extends T3[Concrete] 

In 2.10+ def p2(c:C2) = c.doit(c.get) compiles.
See this scastie snippet.