What is a "context bound" in Scala?

Question

One of the new features of Scala 2.8 are context bounds. What is a context bound and where is it useful?

Of course I searched first (and found for example this) but I couldn't find any really clear and detailed information.

Answer 1

Did you find this article? It covers the new context bound feature, within the context of array improvements.

Generally, a type parameter with a context bound is of the form [T: Bound]; it is expanded to plain type parameter T together with an implicit parameter of type Bound[T].

Consider the method tabulate which forms an array from the results of applying a given function f on a range of numbers from 0 until a given length. Up to Scala 2.7, tabulate could be written as follows:

def tabulate[T](len: Int, f: Int => T) = {
    val xs = new Array[T](len)
    for (i <- 0 until len) xs(i) = f(i)
    xs
}

In Scala 2.8 this is no longer possible, because runtime information is necessary to create the right representation of Array[T]. One needs to provide this information by passing a ClassManifest[T] into the method as an implicit parameter:

def tabulate[T](len: Int, f: Int => T)(implicit m: ClassManifest[T]) = {
    val xs = new Array[T](len)
    for (i <- 0 until len) xs(i) = f(i)
    xs
}

As a shorthand form, a context bound can be used on the type parameter T instead, giving:

def tabulate[T: ClassManifest](len: Int, f: Int => T) = {
    val xs = new Array[T](len)
    for (i <- 0 until len) xs(i) = f(i)
    xs
}

Answer 2

Robert's answer covers the techinal details of Context Bounds. I'll give you my interpretation of their meaning.

In Scala a View Bound (A <% B) captures the concept of 'can be seen as' (whereas an upper bound <: captures the concept of 'is a'). A context bound (A : C) says 'has a' about a type. You can read the examples about manifests as "T has a Manifest". The example you linked to about Ordered vs Ordering illustrates the difference. A method

def example[T <% Ordered[T]](param: T)

says that the parameter can be seen as an Ordered. Compare with

def example[T : Ordering](param: T)

which says that the parameter has an associated Ordering.

In terms of use, I don't think conventions are properly established (because context bounds are new). One suggestion is that their use is preferred when you need to transfer an implicit definition from one scope to another without needing to refer to it directly (this is certainly the case for the ClassManifest used to create an array).

Another way of thinking about view bounds and context bounds is that the first transfers implicit conversions from the caller's scope. The second transfers implicit objects from the caller's scope.

Answer 3

(This is a parenthetical note. Read and understand the other answers first.)

Context Bounds actually generalize View Bounds.

So, given this code expressed with a View Bound:

scala> implicit def int2str(i: Int): String = i.toString
int2str: (i: Int)String

scala> def f1[T <% String](t: T) = 0
f1: [T](t: T)(implicit evidence$1: (T) => String)Int

This could also be expressed with a Context Bound, with the help of a type alias representing functions from type F to type T.

scala> trait To[T] { type From[F] = F => T }           
defined trait To

scala> def f2[T : To[String]#From](t: T) = 0       
f2: [T](t: T)(implicit evidence$1: (T) => java.lang.String)Int

scala> f2(1)
res1: Int = 0

A context bound must be used with a type constructor of kind * => *. However the type constructor Function1 is of kind (*, *) => *. The use of the type alias partially applies second type parameter with the type String, yielding a type constructor of the correct kind for use as a context bound.

There is a proposal to allow you to directly express partially applied types in Scala, without the use of the type alias inside a trait. You could then write:

def f3[T : [X](X => String)](t: T) = 0