Provides functions to deal with modules during compilation time.

It allows a developer to dynamically add, delete and register attributes, attach documentation and so forth.

After a module is compiled, using many of the functions in this module will raise errors, since it is out of their scope to inspect runtime data. Most of the runtime data can be inspected via the __info__/1 function attached to each compiled module.

Module attributes

Each module can be decorated with one or more attributes. The following ones are currently defined by Elixir:

@after_compile

A hook that will be invoked right after the current module is compiled. Accepts a module or a {module, function_name}. See the “Compile callbacks” section below.

@before_compile

A hook that will be invoked before the module is compiled. Accepts a module or a {module, function_or_macro_name} tuple. See the “Compile callbacks” section below.

@behaviour (notice the British spelling)

Behaviours can be referenced by modules to ensure they implement required specific function signatures defined by @callback.

For example, you could specify a URI.Parser behaviour as follows:

defmodule URI.Parser do
  @doc "Defines a default port"
  @callback default_port() :: integer

  @doc "Parses the given URL"
  @callback parse(uri_info :: URI.t) :: URI.t
end

And then a module may use it as:

defmodule URI.HTTP do
  @behaviour URI.Parser
  def default_port(), do: 80
  def parse(info), do: info
end

If the behaviour changes or URI.HTTP does not implement one of the callbacks, a warning will be raised.

@impl

To aid in the correct implementation of behaviours, you may optionally declare @impl for implemented callbacks of a behaviour. This makes callbacks explicit and can help you to catch errors in your code (the compiler will warn you if you mark a function as @impl when in fact it is not a callback, and vice versa). It also helps with maintainability by making it clear to other developers that the function’s purpose is to implement a callback.

Using @impl the example above can be rewritten as:

defmodule URI.HTTP do
  @behaviour URI.parser

  @impl true
  def default_port(), do: 80

  @impl true
  def parse(info), do: info
end

You may pass either false, true, or a specific behaviour to @impl.

defmodule Foo do
  @behaviour Bar
  @behaviour Baz

  @impl true # will warn if neither Bar nor Baz specify a callback named bar/0
  def bar(), do: :ok

  @impl Baz # will warn if Baz does not specify a callback named baz/0
  def baz(), do: :ok
end

@compile

Defines options for module compilation. This is used to configure both Elixir and Erlang compilers, as any other compilation pass added by external tools. For example:

defmodule MyModule do
  @compile {:inline, my_fun: 1}

  def my_fun(arg) do
    to_string(arg)
  end
end

Multiple uses of @compile will accumulate instead of overriding previous ones. See the “Compile options” section below.

@deprecated

Provides the deprecation reason for a function. For example:

defmodule Keyword do
  @deprecated "Use Kernel.length/1 instead"
  def size(keyword) do
    length(keyword)
  end
end

The mix compiler automatically looks for calls to deprecated modules and emit warnings during compilation, computed via mix xref warnings.

We recommend using this feature with care, especially library authors. Deprecating code always pushes the burden towards library users. We also recommend for deprecated functionality to be maintained for long periods of time, even after deprecation, giving developers plenty of time to update (except for cases where keeping the deprecated API is undesired, such as in the presence of security issues).

@doc (and @since)

Provides documentation for the function or macro that follows the attribute.

Accepts a string (often a heredoc) or false where @doc false will make the function/macro invisible to documentation extraction tools like ExDoc. For example:

defmodule MyModule do
  @doc "Hello world"
  @since "1.1.0"
  def hello do
    "world"
  end

  @doc """
  Sums `a` to `b`.
  """
  def sum(a, b) do
    a + b
  end
end

@since is an optional attribute that annotates which version the function was introduced.

@dialyzer

Defines warnings to request or suppress when using a version of :dialyzer that supports module attributes.

Accepts an atom, a tuple, or a list of atoms and tuples. For example:

defmodule MyModule do
  @dialyzer {:nowarn_function, my_fun: 1}

  def my_fun(arg) do
    M.not_a_function(arg)
  end
end

For the list of supported warnings, see :dialyzer module.

Multiple uses of @dialyzer will accumulate instead of overriding previous ones.

@external_resource

Specifies an external resource for the current module.

Sometimes a module embeds information from an external file. This attribute allows the module to annotate which external resources have been used.

Tools like Mix may use this information to ensure the module is recompiled in case any of the external resources change.

@file

Changes the filename used in stacktraces for the function or macro that follows the attribute, such as:

defmodule MyModule do
  @doc "Hello world"
  @file "hello.ex"
  def hello do
    "world"
  end
end

@moduledoc

Provides documentation for the current module.

defmodule MyModule do
  @moduledoc """
  A very useful module.
  """
end

Accepts a string (often a heredoc) or false where @moduledoc false will make the module invisible to documentation extraction tools like ExDoc.

@on_definition

A hook that will be invoked when each function or macro in the current module is defined. Useful when annotating functions.

Accepts a module or a {module, function_name} tuple. See the “Compile callbacks” section below.

@on_load

A hook that will be invoked whenever the module is loaded.

Accepts the function name (as an atom) of a function in the current module or {function_name, 0} tuple where function_name is the name of a function in the current module. The function must have arity 0 (no arguments) and has to return :ok, otherwise the loading of the module will be aborted. For example:

defmodule MyModule do
  @on_load :load_check

  def load_check do
    if some_condition() do
      :ok
    else
      :abort
    end
  end

  def some_condition do
    false
  end
end

Modules compiled with HiPE would not call this hook.

@vsn

Specify the module version. Accepts any valid Elixir value, for example:

defmodule MyModule do
  @vsn "1.0"
end

Typespec attributes

The following attributes are part of typespecs and are also reserved by Elixir:

• @type - defines a type to be used in @spec
• @typep - defines a private type to be used in @spec
• @opaque - defines an opaque type to be used in @spec
• @spec - provides a specification for a function
• @callback - provides a specification for a behaviour callback
• @macrocallback - provides a specification for a macro behaviour callback
• @optional_callbacks - specifies which behaviour callbacks and macro behaviour callbacks are optional
• @impl - declares an implementation of a callback function or macro

Custom attributes

In addition to the built-in attributes outlined above, custom attributes may also be added. A custom attribute is any valid identifier prefixed with an @ and followed by a valid Elixir value:

defmodule MyModule do
  @custom_attr [some: "stuff"]
end

For more advanced options available when defining custom attributes, see register_attribute/3.

Compile callbacks

There are three callbacks that are invoked when functions are defined, as well as before and immediately after the module bytecode is generated.

@after_compile

A hook that will be invoked right after the current module is compiled.

Accepts a module or a {module, function_name} tuple. The function must take two arguments: the module environment and its bytecode. When just a module is provided, the function is assumed to be __after_compile__/2.

Callbacks registered first will run last.

Example

defmodule MyModule do
  @after_compile __MODULE__

  def __after_compile__(env, _bytecode) do
    IO.inspect env
  end
end

@before_compile

A hook that will be invoked before the module is compiled.

Accepts a module or a {module, function_or_macro_name} tuple. The function/macro must take one argument: the module environment. If it’s a macro, its returned value will be injected at the end of the module definition before the compilation starts.

When just a module is provided, the function/macro is assumed to be __before_compile__/1.

Callbacks registered first will run last. Any overridable definition will be made concrete before the first callback runs. A definition may be made overridable again in another before compile callback and it will be made concrete one last time after after all callbacks run.

Note: unlike @after_compile, the callback function/macro must be placed in a separate module (because when the callback is invoked, the current module does not yet exist).

Example

defmodule A do
  defmacro __before_compile__(_env) do
    quote do
      def hello, do: "world"
    end
  end
end

defmodule B do
  @before_compile A
end

B.hello()
#=> "world"

@on_definition

A hook that will be invoked when each function or macro in the current module is defined. Useful when annotating functions.

Accepts a module or a {module, function_name} tuple. The function must take 6 arguments:

• the module environment
• the kind of the function/macro: :def, :defp, :defmacro, or :defmacrop
• the function/macro name
• the list of quoted arguments
• the list of quoted guards
• the quoted function body

Note the hook receives the quoted arguments and it is invoked before the function is stored in the module. So Module.defines?/2 will return false for the first clause of every function.

If the function/macro being defined has multiple clauses, the hook will be called for each clause.

Unlike other hooks, @on_definition will only invoke functions and never macros. This is to avoid @on_definition callbacks from redefining functions that have just been defined in favor of more explicit approaches.

When just a module is provided, the function is assumed to be __on_definition__/6.

Example

defmodule Hooks do
  def on_def(_env, kind, name, args, guards, body) do
    IO.puts "Defining #{kind} named #{name} with args:"
    IO.inspect args
    IO.puts "and guards"
    IO.inspect guards
    IO.puts "and body"
    IO.puts Macro.to_string(body)
  end
end

defmodule MyModule do
  @on_definition {Hooks, :on_def}

  def hello(arg) when is_binary(arg) or is_list(arg) do
    "Hello" <> to_string(arg)
  end

  def hello(_) do
    :ok
  end
end

Compile options

The @compile attribute accepts different options that are used by both Elixir and Erlang compilers. Some of the common use cases are documented below:

• @compile :debug_info - includes :debug_info regardless of the corresponding setting in Code.compiler_options/1

• @compile {:debug_info, false} - disables :debug_info regardless of the corresponding setting in Code.compiler_options/1

• @compile {:inline, some_fun: 2, other_fun: 3} - inlines the given name/arity pairs

• @compile {:autoload, false} - disables automatic loading of modules after compilation. Instead, the module will be loaded after it is dispatched to

You can see a handful more options used by the Erlang compiler in the documentation for the :compile module.