14

Recently I've noticed that variance annotations can be used in type aliases. Here is example from Predef:

type Function[-A, +B] = Function1[A, B]

And I started to think, where it could be used. Obviously, you can't change variance to opposite, or make an invariant type to behave as co- or contravariant. Compiler will throw an error, like this

scala> type BrokenFunc[+T, -R] = Function1[T, R]
<console>:7: error: covariant type T occurs in contravariant position in type 
  [+T, -R]T => R of type BrokenFunc

But, you can make some variant type to behave like invariant (at least, compiler wouldn't argue with that). So, I tried to make an invariant version of List

scala> type InvList[T] = List[T]
defined type alias InvList

But this new invariant List still behaves just like it's original covariant version:

scala> val l: InvList[String] = List("foo")
l: InvList[String] = List(foo)

scala> val anyList: InvList[Any] = l
anyList: InvList[Any] = List(foo)

So, what I am missing? What's the purpose of variance annotations in type aliases? Can you give an example of type alias with variance annotations, that will differ from original type.

4e6
  • 10,696
  • 4
  • 52
  • 62

2 Answers2

9

So, I don't know for sure, but I'm going to offer a possible explanation.

Type aliases in Scala are fairly "weak"; they do not completely create new types, just new ways of writing the old types (and new path dependent types); this means that if you define

type InvList[T] = List[T]

and write InvList[T], it is exactly as if you wrote List[T]; that's why InvList[Int] <: InvList[Any], because, rewritten, this is just List[Int] <: List[Any]. I'm not actually sure exactly how "weak" Scala type aliases are... they are a little stronger than Haskell's because of path-dependent types, but are weaker than class declarations. Maybe someone else can explain further.

So, why does Scala allow you to put variance annotations in there, if it's just going to ignore them and rewrite the type anyway? It's for type members. It's so that you can say

trait A { type F[+T] }

and require that implementations conform to the +T variance, so that you allow

trait B extends A { type F[+T] = List[T] }

but not

trait C extends A { type F[T] = Function[T,T] }

Or, as from this sentence from the Scala Language Spec S4.3.

A type constructor declaration imposes additional restrictions on the concrete types for which t may stand. Besides the bounds L and U , the type parameter clause may impose higher-order bounds and variances, as governed by the conformance of type constructors (§3.5.2).

Owen
  • 38,836
  • 14
  • 95
  • 125
  • I also wouldn't say, that type aliases are "weak", because they are what they are (aliases). I think it's a great feature, and it's utterly missing in Java. How often did I want to have a shorter name for things like Map,Map> without having to define a dedicated class with all required consequences. – Thipor Kong May 10 '12 at 07:43
  • @ThiporKong wrt point 1, I tried it in the REPL and it works OK, so I think it should be good. wrt point 2, you're right, "weak" could be a misleading word, but it's the word I've heard used for this before (eg typedef in C, type aliases in Haskell). Weak doesn't mean bad. But is there a better word I could use? – Owen May 10 '12 at 07:46
  • Re. Function -- yes, of course, you're right. Don't know what I've seen. – Thipor Kong May 10 '12 at 09:04
  • @Owen, yes, it seems that type aliases just rewrites old types, and compiler only ensures you are not writing something crazy. Now, with your example, it makes sense for me. Thanks. – 4e6 May 11 '12 at 11:41
2

If the abstract type is only declared (as in Domain), the invariance will be enforced. If the abstract type is defined to have a more relaxed variance, this is respected once known (as in DomainImpl):

trait Domain {
  type InvList[T]

  val xi: InvList[Int]
  private val xa: InvList[Any] = xi // won't compile
}

class DomainImpl extends Domain {
  type InvList[T] = List[T]

  val xi: InvList[Int] = List(1)
  private val xa: InvList[Any] = xi // will compile
}
Thipor Kong
  • 597
  • 3
  • 8