Package scala.annotation

package annotation

Package Members

package meta

When defining a field, the Scala compiler creates up to four accessors for it: a getter, a setter, and if the field is annotated with @BeanProperty, a bean getter and a bean setter.

For instance in the following class definition

class C(@myAnnot @BeanProperty var c: Int)

there are six entities which can carry the annotation @myAnnot: the constructor parameter, the generated field and the four accessors.

By default, annotations on (val-, var- or plain) constructor parameters end up on the parameter, not on any other entity. Annotations on fields by default only end up on the field.

The meta-annotations in package scala.annotation.meta are used to control where annotations on fields and class parameters are copied. This is done by annotating either the annotation type or the annotation class with one or several of the meta-annotations in this package.

Annotating the annotation type

The target meta-annotations can be put on the annotation type when instantiating the annotation. In the following example, the annotation @Id will be added only to the bean getter getX.

import javax.persistence.Id
class A {
  @(Id @beanGetter) @BeanProperty val x = 0
}

In order to annotate the field as well, the meta-annotation @field would need to be added.

The syntax can be improved using a type alias:

object ScalaJPA {
  type Id = javax.persistence.Id @beanGetter
}
import ScalaJPA.Id
class A {
  @Id @BeanProperty val x = 0
}

Annotating the annotation class

For annotations defined in Scala, a default target can be specified in the annotation class itself, for example

@getter
class myAnnotation extends Annotation

This only changes the default target for the annotation myAnnotation. When instantiating the annotation, the target can still be specified as described in the last section.

package unchecked

Type Members

abstract class Annotation extends AnyRef

A base class for annotations.

Annotations extending this class directly are not preserved in the classfile. To enable storing annotations in the classfile's Scala signature and make it available to Scala reflection and other tools, the annotation needs to inherit from scala.annotation.StaticAnnotation.

Annotation classes defined in Scala are not stored in classfiles in a Java-compatible manner and therefore not visible in Java reflection. In order to achieve this, the annotation has to be written in Java.

Since

2.4

trait ConstantAnnotation extends Annotation with StaticAnnotation

Annotation classes extending this trait only accept constant values as arguments.

Note that this trait extends StaticAnnotation, so constant annotations are persisted in the classfile.

The implementation requires arguments of constant annotations to be passed as named arguments, except if there is a single argument, which then defines the annotation's parameter named value.

Constant annotations may use default arguments. Note that the internal representation of an annotation usage (which is visible for compiler plugins, for example) only contains arguments that are explicitly provided.

Constant annotations are not allowed to define auxiliary constructors, and the primary constructor is required to have a single parameter list.

Example:

class Ann(value: Int, x: Int = 0) extends scala.annotation.ConstantAnnotation
class Test {
  def someInt = 0
  @Ann(value = 0, x = 1) def g = 0
  @Ann(0) def f = 0                 // Internal representation contains `@Ann(value = 0)`
  @Ann(someInt)                     // error: argument needs to be a compile-time constant
}

trait StaticAnnotation extends Annotation

A base class for static annotations. These are available to the Scala type checker or Scala reflection, even across different compilation units.

Annotation classes defined in Scala are not stored in classfiles in a Java-compatible manner and therefore not visible in Java reflection. In order to achieve this, the annotation has to be written in Java.

Since

2.4

trait TypeConstraint extends Annotation

A marker for annotations that, when applied to a type, should be treated as a constraint on the annotated type.

A proper constraint should restrict the type based only on information mentioned within the type. A Scala compiler can use this assumption to rewrite the contents of the constraint as necessary. To contrast, a type annotation whose meaning depends on the context where it is written down is not a proper constrained type, and this marker should not be applied. A Scala compiler will drop such annotations in cases where it would rewrite a type constraint.

Since

2.6

final class compileTimeOnly extends Annotation with StaticAnnotation

An annotation that designates that an annottee should not be referred to after type checking (which includes macro expansion).

Examples of potential use: 1) The annottee can only appear in the arguments of some other macro that will eliminate it from the AST during expansion. 2) The annottee is a macro and should have been expanded away, so if hasn't, something wrong has happened. (Comes in handy to provide better support for new macro flavors, e.g. macro annotations, that can't be expanded by the vanilla compiler).

Annotations
@getter() @setter() @beanGetter() @beanSetter() @companionClass() @companionMethod()
Since

2.11.0

final class elidable extends Annotation with StaticAnnotation

An annotation for methods whose bodies may be excluded from compiler-generated bytecode.

Behavior is influenced by passing -Xelide-below <arg> to scalac. Calls to methods marked elidable (as well as the method body) will be omitted from generated code if the priority given the annotation is lower than that given on the command line.

@elidable(123)           // annotation priority
scalac -Xelide-below 456 // command line priority

The method call will be replaced with an expression which depends on the type of the elided expression. In decreasing order of precedence:

Unit            ()
Boolean         false
T <: AnyVal     0
T >: Null       null
T >: Nothing    Predef.???

Complete example:

import scala.annotation._, elidable._
object Test extends App {
  def expensiveComputation(): Int = { Thread.sleep(1000) ; 172 }

  @elidable(WARNING) def warning(msg: String) = println(msg)
  @elidable(FINE) def debug(msg: String)      = println(msg)
  @elidable(FINE) def computedValue           = expensiveComputation()

  warning("Warning! Danger! Warning!")
  debug("Debug! Danger! Debug!")
  println("I computed a value: " + computedValue)
}
% scalac example.scala && scala Test
Warning! Danger! Warning!
Debug! Danger! Debug!
I computed a value: 172

// INFO lies between WARNING and FINE
% scalac -Xelide-below INFO example.scala && scala Test
Warning! Danger! Warning!
I computed a value: 0

Note that only concrete methods can be marked @elidable. A non-annotated method is not elided, even if it overrides / implements a method that has the annotation.

Also note that the static type determines which annotations are considered:

import scala.annotation._, elidable._
class C { @elidable(0) def f(): Unit = ??? }
object O extends C { override def f(): Unit = println("O.f") }
object Test extends App {
  O.f()      // not elided
  (O: C).f() // elided if compiled with `-Xelide-below 1`
}
Since

2.8

final class implicitAmbiguous extends Annotation with StaticAnnotation

To customize the error message that's emitted when an implicit search finds multiple ambiguous values, annotate at least one of the implicit values @implicitAmbiguous. Assuming the implicit value is a method with type parameters X1,..., XN, the error message will be the result of replacing all occurrences of ${Xi} in the string msg with the string representation of the corresponding type argument Ti.

If more than one @implicitAmbiguous annotation is collected, the compiler is free to pick any of them to display.

Nice errors can direct users to fix imports or even tell them why code intentionally doesn't compile.

trait =!=[C, D]

implicit def neq[E, F] : E =!= F = null

@annotation.implicitAmbiguous("Could not prove ${J} =!= ${J}")
implicit def neqAmbig1[G, H, J] : J =!= J = null
implicit def neqAmbig2[I] : I =!= I = null

implicitly[Int =!= Int]
Annotations
@getter()
Since

2.12.0

final class implicitNotFound extends Annotation with StaticAnnotation

To customize the error message that's emitted when an implicit of type C[T1,..., TN] cannot be found, annotate the class C with @implicitNotFound. Assuming C has type parameters X1, ..., XN, the error message will be the result of replacing all occurrences of ${Xi} in the string msg with the string representation of the corresponding type argument Ti.

The annotation can also be attached to implicit parameters. In this case, ${Xi} can refer to type parameters in the current scope. The @implicitNotFound message on the parameter takes precedence over the one on the parameter's type.

import scala.annotation.implicitNotFound

@implicitNotFound("Could not find an implicit C[${T}, ${U}]")
class C[T, U]

class K[A] {
  def m[B](implicit c: C[List[A], B]) = 0
  def n[B](implicit @implicitNotFound("Specific message for C of list of ${A} and ${B}") c: C[List[A], B]) = 1
}

object Test {
  val k = new K[Int]
  k.m[String]
  k.n[String]
}

The compiler issues the following error messages:

Test.scala:13: error: Could not find an implicit C[List[Int], String]
  k.m[String]
     ^
Test.scala:14: error: Specific message for C of list of Int and String
  k.n[String]
     ^
Since

2.8.1

class showAsInfix extends Annotation with StaticAnnotation

This annotation configures how Scala prints two-parameter generic types.

By default, types with symbolic names are printed infix; while types without them are printed using the regular generic type syntax.

Example of usage:

scala> class Map[T, U]
defined class Map

scala> def foo: Int Map Int = ???
foo: Map[Int,Int]

scala> @showAsInfix class Map[T, U]
defined class Map

scala> def foo: Int Map Int = ???
foo: Int Map Int
Annotations
@deprecatedInheritance("Scheduled for being final in 2.14", "2.13.0")
Since

2.12.2

class strictfp extends Annotation with StaticAnnotation

If this annotation is present on a method or its enclosing class, the strictfp flag will be emitted.

Annotations
@deprecatedInheritance("Scheduled for being final in 2.14", "2.13.0")
Since

2.9

final class switch extends Annotation with StaticAnnotation

An annotation to be applied to a match expression. If present, the compiler will verify that the match has been compiled to a tableswitch or lookupswitch and issue an error if it instead compiles into a series of conditional expressions. Example usage:

val Constant = 'Q'
def tokenMe(ch: Char) = (ch: @switch) match {
  case ' ' | '\t' | '\n'  => 1
  case 'A' | 'Z' | '$'    => 2
  case '5' | Constant     => 3  // a non-literal may prevent switch generation: this would not compile
  case _                  => 4
}

Note: for pattern matches with one or two cases, the compiler generates jump instructions. Annotating such a match with @switch does not issue any warning.

Since

2.8

final class tailrec extends Annotation with StaticAnnotation

A method annotation which verifies that the method will be compiled with tail call optimization.

If it is present, the compiler will issue an error if the method cannot be optimized into a loop.

Since

2.8

class unspecialized extends Annotation with StaticAnnotation

A method annotation which suppresses the creation of additional specialized forms based on enclosing specialized type parameters.

Annotations
@deprecatedInheritance("Scheduled for being final in 2.14", "2.13.0")
Since

2.10

class unused extends Annotation with StaticAnnotation

Mark an element unused for a given context.

Unused warnings are suppressed for elements known to be unused.

For example, a method parameter may be marked @unused because the method is designed to be overridden by an implementation that does use the parameter.

Annotations
@getter() @setter()

final class varargs extends Annotation with StaticAnnotation

A method annotation which instructs the compiler to generate a Java varargs-style forwarder method for interop. This annotation can only be applied to methods with repeated parameters.

Since

2.9

Value Members

object elidable

This useless appearing code was necessary to allow people to use named constants for the elidable annotation. This is what it takes to convince the compiler to fold the constants: otherwise when it's time to check an elision level it's staring at a tree like

(Select(Level, Select(FINEST, Apply(intValue, Nil))))

instead of the number 300.

Since

2.8

© 2002-2019 EPFL, with contributions from Lightbend.
Licensed under the Apache License, Version 2.0.
https://www.scala-lang.org/api/2.13.0/scala/annotation/index.html