TypeTags

Type tags encapsulate a representation of type T. They are supposed to replace the pre-2.10 concept of a scala.reflect.Manifest. TypeTags are much better integrated with reflection than manifests are, and are consequently much simpler.

Overview

Type tags are organized in a hierarchy of three classes: scala.reflect.ClassTag, scala.reflect.base.Universe#TypeTag and scala.reflect.base.Universe#AbsTypeTag.

A scala.reflect.ClassTag carries a runtime class that corresponds to the source type T. As of such, it possesses the knowledge about how to build single- and multi-dimensional arrays of elements of that type. It guarantees that the source type T did not to contain any references to type parameters or abstract types. scala.reflect.ClassTag corresponds to a previous notion of scala.reflect.ClassManifest.

A scala.reflect.base.Universe#AbsTypeTag value wraps a full Scala type in its tpe field. A scala.reflect.base.Universe#TypeTag value is an scala.reflect.base.Universe#AbsTypeTag that is guaranteed not to contain any references to type parameters or abstract types.

[Eugene++] also mention sensitivity to prefixes, i.e. that rb.TypeTag is different from ru.TypeTag [Eugene++] migratability between mirrors and universes is also worth mentioning

Splicing

Tags can be spliced, i.e. if compiler generates a tag for a type that contains references to tagged type parameters or abstract type members, it will retrieve the corresponding tag and embed it into the result. An example that illustrates the TypeTag embedding, consider the following function:

import reflect.mirror._ def f[T: TypeTag, U] = { type L = T => U implicitly[AbsTypeTag[L]] }

Then a call of f[String, Int] will yield a result of the form

AbsTypeTag(<[ String => U ]>).

Note that T has been replaced by String, because it comes with a TypeTag in f, whereas U was left as a type parameter.

AbsTypeTag vs TypeTag

Be careful with AbsTypeTag, because it will reify types even if these types are abstract. This makes it easy to forget to tag one of the methods in the call chain and discover it much later in the runtime by getting cryptic errors far away from their source. For example, consider the following snippet:

def bind[T: AbsTypeTag](name: String, value: T): IR.Result = bind((name, value)) def bind(p: NamedParam): IR.Result = bind(p.name, p.tpe, p.value) object NamedParam { implicit def namedValue[T: AbsTypeTag](name: String, x: T): NamedParam = apply(name, x) def apply[T: AbsTypeTag](name: String, x: T): NamedParam = new Typed[T](name, x) }

This fragment of Scala REPL implementation defines a bind function that carries a named value along with its type into the heart of the REPL. Using a scala.reflect.base.Universe#AbsTypeTag here is reasonable, because it is desirable to work with all types, even if they are type parameters or abstract type members.

However if any of the three AbsTypeTag context bounds is omitted, the resulting code will be incorrect, because the missing AbsTypeTag will be transparently generated by the compiler, carrying meaningless information. Most likely, this problem will manifest itself elsewhere, making debugging complicated. If AbsTypeTag context bounds were replaced with TypeTag, then such errors would be reported statically. But in that case we wouldn't be able to use bind in arbitrary contexts.

Backward compatibility

Type tags correspond loosely to manifests.

More precisely: The previous notion of a scala.reflect.ClassManifest corresponds to a scala.reflect.ClassTag, The previous notion of a scala.reflect.Manifest corresponds to scala.reflect.runtime.universe.TypeTag,

In Scala 2.10, manifests are deprecated, so it's adviseable to migrate them to tags, because manifests might be removed in the next major release.

In most cases it will be enough to replace ClassManifests with ClassTags and Manifests with TypeTags, however there are a few caveats:

1) The notion of OptManifest is no longer supported. Tags can reify arbitrary types, so they are always available. // [Eugene++] it might be useful, though, to guard against abstractness of the incoming type.

2) There's no equivalent for AnyValManifest. Consider comparing your tag with one of the base tags (defined in the corresponding companion objects) to find out whether it represents a primitive value class. You can also use <tag>.tpe.typeSymbol.isPrimitiveValueClass for that purpose (requires scala-reflect.jar).

3) There's no replacement for factory methods defined in ClassManifest and Manifest companion objects. Consider assembling corresponding types using reflection API provided by Java (for classes) and Scala (for types).

4) Certain manifest functions (such as <:<, >:> and typeArguments) weren't included in the tag API. Consider using reflection API provided by Java (for classes) and Scala (for types) instead.