When an annotation class extends this trait, annotation processing macros (e.g.
When applied on varargs parameter, indicates that at least some number of parameters is required.
When applied on varargs parameter, indicates that at least some number of parameters is required.
This is later checked by the static analyzer.
WARNING: implementation of method which takes a varargs parameter may NOT assume that given number of
arguments will always be passed, because it's still possible to pass a Seq
where
varargs parameter is required using the : _*
ascription, e.g.
varargsMethod(List(): _*)
and that is not checked by the static analyzer.
When applied on generic method, requires that all the type parameters are given explicitly (cannot be inferred by the compiler).
When applied on generic method, requires that all the type parameters are given explicitly
(cannot be inferred by the compiler). This is meant primarily for methods whose generics cannot be
inferred from method arguments. Requiring that the programmer specifies them explicitly is a protection
against the compiler inferring Nothing
or Null
.
@explicitGenerics def readJson[T: GenCodec](json: String): T = ... // raise error, because otherwise we have a hidden bug - the compiler infers `Nothing` in place of `T` val x: MyType = readJson("{}") // ok val x = readJson[MyType]("{}")
Symbols annotated with this annotation can only be used in macro-generated code.
When an annotation class extends this trait, annotation processing macros (e.g. for
GenCodec
materialization) will look into annotations of the aggregating annotation itself and apply these annotations as if they were applied directly on the same target as the aggregating annotation. Example:In the above example, applying
@mongoId
annotation on theid
field has the same effect as if annotations@name("_id") @outOfOrder
were applied directly on that field.