Boolean not.

Receives any argument (not just booleans) and returns true if the argument is false or nil; returns false otherwise.

Not allowed in guard clauses.

Examples

iex> !Enum.empty?([])
false

iex> !List.first([])
true

Provides a short-circuit operator that evaluates and returns the second expression only if the first one evaluates to to a truthy value (neither false nor nil). Returns the first expression otherwise.

Not allowed in guard clauses.

Examples

iex> Enum.empty?([]) && Enum.empty?([])
true

iex> List.first([]) && true
nil

iex> Enum.empty?([]) && List.first([1])
1

iex> false && throw(:bad)
false

Note that, unlike and/2, this operator accepts any expression as the first argument, not only booleans.

Specs

list() ++ term() :: maybe_improper_list()

Concatenates a proper list and a term, returning a list.

The complexity of a ++ b is proportional to length(a), so avoid repeatedly appending to lists of arbitrary length, e.g. list ++ [item]. Instead, consider prepending via [item | rest] and then reversing.

If the right operand is not a proper list, it returns an improper list. If the left operand is not a proper list, it raises ArgumentError.

Inlined by the compiler.

Examples

iex> [1] ++ [2, 3]
[1, 2, 3]

iex> 'foo' ++ 'bar'
'foobar'

# returns an improper list
iex> [1] ++ 2
[1 | 2]

# returns a proper list
iex> [1] ++ [2]
[1, 2]

# improper list on the right will return an improper list
iex> [1] ++ [2 | 3]
[1, 2 | 3]

Specs

list() -- list() :: list()

Removes the first occurrence of an item on the left list for each item on the right.

The complexity of a -- b is proportional to length(a) * length(b), meaning that it will be very slow if both a and b are long lists. In such cases, consider converting each list to a MapSet and using MapSet.difference/2.

Inlined by the compiler.

Examples

iex> [1, 2, 3] -- [1, 2]
[3]

iex> [1, 2, 3, 2, 1] -- [1, 2, 2]
[3, 1]

Returns a range with the specified first and last integers.

If last is larger than first, the range will be increasing from first to last. If first is larger than last, the range will be decreasing from first to last. If first is equal to last, the range will contain one element, which is the number itself.

Examples

iex> 0 in 1..3
false

iex> 1 in 1..3
true

iex> 2 in 1..3
true

iex> 3 in 1..3
true

Concatenates two binaries.

Examples

iex> "foo" <> "bar"
"foobar"

The <>/2 operator can also be used in pattern matching (and guard clauses) as long as the left argument is a literal binary:

iex> "foo" <> x = "foobar"
iex> x
"bar"

x <> "bar" = "foobar" would have resulted in a CompileError exception.

Specs

String.t() =~ (String.t() | Regex.t()) :: boolean()

Matches the term on the left against the regular expression or string on the right.

Returns true if left matches right (if it's a regular expression) or contains right (if it's a string).

Examples

iex> "abcd" =~ ~r/c(d)/
true

iex> "abcd" =~ ~r/e/
false

iex> "abcd" =~ "bc"
true

iex> "abcd" =~ "ad"
false

iex> "abcd" =~ ""
true

Reads and writes attributes of the current module.

The canonical example for attributes is annotating that a module implements an OTP behaviour, such as GenServer:

defmodule MyServer do
  @behaviour GenServer
  # ... callbacks ...
end

By default Elixir supports all the module attributes supported by Erlang, but custom attributes can be used as well:

defmodule MyServer do
  @my_data 13
  IO.inspect(@my_data) #=> 13
end

Unlike Erlang, such attributes are not stored in the module by default since it is common in Elixir to use custom attributes to store temporary data that will be available at compile-time. Custom attributes may be configured to behave closer to Erlang by using Module.register_attribute/3.

Finally, notice that attributes can also be read inside functions:

defmodule MyServer do
  @my_data 11
  def first_data, do: @my_data
  @my_data 13
  def second_data, do: @my_data
end

MyServer.first_data()
#=> 11

MyServer.second_data()
#=> 13

It is important to note that reading an attribute takes a snapshot of its current value. In other words, the value is read at compilation time and not at runtime. Check the Module module for other functions to manipulate module attributes.

When used inside quoting, marks that the given alias should not be hygienized. This means the alias will be expanded when the macro is expanded.

Check Kernel.SpecialForms.quote/2 for more information.

Specs

apply((... -> any()), [any()]) :: any()

Invokes the given anonymous function fun with the list of arguments args.

Inlined by the compiler.

Examples

iex> apply(fn x -> x * 2 end, [2])
4

Specs

apply(module(), function_name :: atom(), [any()]) :: any()

Invokes the given function from module with the list of arguments args.

apply/3 is used to invoke functions where the module, function name or arguments are defined dynamically at runtime. For this reason, you can't invoke macros using apply/3, only functions.

Inlined by the compiler.

Examples

iex> apply(Enum, :reverse, [[1, 2, 3]])
[3, 2, 1]

Returns the binding for the given context as a keyword list.

In the returned result, keys are variable names and values are the corresponding variable values.

If the given context is nil (by default it is), the binding for the current context is returned.

Examples

iex> x = 1
iex> binding()
[x: 1]
iex> x = 2
iex> binding()
[x: 2]

iex> binding(:foo)
[]
iex> var!(x, :foo) = 1
1
iex> binding(:foo)
[x: 1]

Defines a function with the given name and body.

Examples

defmodule Foo do
  def bar, do: :baz
end

Foo.bar()
#=> :baz

A function that expects arguments can be defined as follows:

defmodule Foo do
  def sum(a, b) do
    a + b
  end
end

In the example above, a sum/2 function is defined; this function receives two arguments and returns their sum.

Default arguments

\\ is used to specify a default value for a parameter of a function. For example:

defmodule MyMath do
  def multiply_by(number, factor \\ 2) do
    number * factor
  end
end

MyMath.multiply_by(4, 3)
#=> 12

MyMath.multiply_by(4)
#=> 8

The compiler translates this into multiple functions with different arities, here Foo.multiply_by/1 and Foo.multiply_by/2, that represent cases when arguments for parameters with default values are passed or not passed.

When defining a function with default arguments as well as multiple explicitly declared clauses, you must write a function head that declares the defaults. For example:

defmodule MyString do
  def join(string1, string2 \\ nil, separator \\ " ")

  def join(string1, nil, _separator) do
    string1
  end

  def join(string1, string2, separator) do
    string1 <> separator <> string2
  end
end

Note that \\ can't be used with anonymous functions because they can only have a sole arity.

Function and variable names

Function and variable names have the following syntax: A lowercase ASCII letter or an underscore, followed by any number of lowercase or uppercase ASCII letters, numbers, or underscores. Optionally they can end in either an exclamation mark or a question mark.

For variables, any identifier starting with an underscore should indicate an unused variable. For example:

def foo(bar) do
  []
end
#=> warning: variable bar is unused

def foo(_bar) do
  []
end
#=> no warning

def foo(_bar) do
  _bar
end
#=> warning: the underscored variable "_bar" is used after being set

rescue/catch/after/else

Function bodies support rescue, catch, after, and else as Kernel.SpecialForms.try/1 does. For example, the following two functions are equivalent:

def format(value) do
  try do
    format!(value)
  catch
    :exit, reason -> {:error, reason}
  end
end

def format(value) do
  format!(value)
catch
  :exit, reason -> {:error, reason}
end

Defines a function that delegates to another module.

Functions defined with defdelegate/2 are public and can be invoked from outside the module they're defined in (like if they were defined using def/2). When the desire is to delegate as private functions, import/2 should be used.

Delegation only works with functions; delegating macros is not supported.

Check def/2 for rules on naming and default arguments.

Options

• :to - the module to dispatch to.

• :as - the function to call on the target given in :to. This parameter is optional and defaults to the name being delegated (funs).

Examples

defmodule MyList do
  defdelegate reverse(list), to: Enum
  defdelegate other_reverse(list), to: Enum, as: :reverse
end

MyList.reverse([1, 2, 3])
#=> [3, 2, 1]

MyList.other_reverse([1, 2, 3])
#=> [3, 2, 1]

Defines an exception.

Exceptions are structs backed by a module that implements the Exception behaviour. The Exception behaviour requires two functions to be implemented:

• exception/1 - receives the arguments given to raise/2 and returns the exception struct. The default implementation accepts either a set of keyword arguments that is merged into the struct or a string to be used as the exception's message.

• message/1 - receives the exception struct and must return its message. Most commonly exceptions have a message field which by default is accessed by this function. However, if an exception does not have a message field, this function must be explicitly implemented.

Since exceptions are structs, the API supported by defstruct/1 is also available in defexception/1.

Raising exceptions

The most common way to raise an exception is via raise/2:

defmodule MyAppError do
  defexception [:message]
end

value = [:hello]

raise MyAppError,
  message: "did not get what was expected, got: #{inspect(value)}"

In many cases it is more convenient to pass the expected value to raise/2 and generate the message in the Exception.exception/1 callback:

defmodule MyAppError do
  defexception [:message]

  @impl true
  def exception(value) do
    msg = "did not get what was expected, got: #{inspect(value)}"
    %MyAppError{message: msg}
  end
end

raise MyAppError, value

The example above shows the preferred strategy for customizing exception messages.

Specs

defguard(Macro.t()) :: Macro.t()

Generates a macro suitable for use in guard expressions.

It raises at compile time if the definition uses expressions that aren't allowed in guards, and otherwise creates a macro that can be used both inside or outside guards.

Note the convention in Elixir is to name functions/macros allowed in guards with the is_ prefix, such as is_list/1. If, however, the function/macro returns a boolean and is not allowed in guards, it should have no prefix and end with a question mark, such as Keyword.keyword?/1.

Example

defmodule Integer.Guards do
  defguard is_even(value) when is_integer(value) and rem(value, 2) == 0
end

defmodule Collatz do
  @moduledoc "Tools for working with the Collatz sequence."
  import Integer.Guards

  @doc "Determines the number of steps `n` takes to reach `1`."
  # If this function never converges, please let me know what `n` you used.
  def converge(n) when n > 0, do: step(n, 0)

  defp step(1, step_count) do
    step_count
  end

  defp step(n, step_count) when is_even(n) do
    step(div(n, 2), step_count + 1)
  end

  defp step(n, step_count) do
    step(3 * n + 1, step_count + 1)
  end
end

Specs

defguardp(Macro.t()) :: Macro.t()

Generates a private macro suitable for use in guard expressions.

It raises at compile time if the definition uses expressions that aren't allowed in guards, and otherwise creates a private macro that can be used both inside or outside guards in the current module.

Similar to defmacrop/2, defguardp/1 must be defined before its use in the current module.

Defines an implementation for the given protocol.

See defprotocol/2 for more information and examples on protocols.

Inside an implementation, the name of the protocol can be accessed via @protocol and the current target as @for.

Defines a macro with the given name and body.

Check def/2 for rules on naming and default arguments.

Examples

defmodule MyLogic do
  defmacro unless(expr, opts) do
    quote do
      if !unquote(expr), unquote(opts)
    end
  end
end

require MyLogic

MyLogic.unless false do
  IO.puts("It works")
end

Defines a private macro with the given name and body.

Private macros are only accessible from the same module in which they are defined.

Check defmacro/2 for more information, and check def/2 for rules on naming and default arguments.

Defines a module given by name with the given contents.

This macro defines a module with the given alias as its name and with the given contents. It returns a tuple with four elements:

• :module
• the module name
• the binary contents of the module
• the result of evaluating the contents block

Examples

iex> defmodule Foo do
...>   def bar, do: :baz
...> end
iex> Foo.bar()
:baz

Nesting

Nesting a module inside another module affects the name of the nested module:

defmodule Foo do
  defmodule Bar do
  end
end

In the example above, two modules - Foo and Foo.Bar - are created. When nesting, Elixir automatically creates an alias to the inner module, allowing the second module Foo.Bar to be accessed as Bar in the same lexical scope where it's defined (the Foo module).

If the Foo.Bar module is moved somewhere else, the references to Bar in the Foo module need to be updated to the fully-qualified name (Foo.Bar) or an alias has to be explicitly set in the Foo module with the help of Kernel.SpecialForms.alias/2.

defmodule Foo.Bar do
  # code
end

defmodule Foo do
  alias Foo.Bar
  # code here can refer to "Foo.Bar" as just "Bar"
end

Module names

A module name can be any atom, but Elixir provides a special syntax which is usually used for module names. What is called a module name is an uppercase ASCII letter followed by any number of lowercase or uppercase ASCII letters, numbers, or underscores. This identifier is equivalent to an atom prefixed by Elixir.. So in the defmodule Foo example Foo is equivalent to :"Elixir.Foo"

Dynamic names

Elixir module names can be dynamically generated. This is very useful when working with macros. For instance, one could write:

defmodule String.to_atom("Foo#{1}") do
  # contents ...
end

Elixir will accept any module name as long as the expression passed as the first argument to defmodule/2 evaluates to an atom. Note that, when a dynamic name is used, Elixir won't nest the name under the current module nor automatically set up an alias.

Reserved module names

If you attempt to define a module that already exists, you will get a warning saying that a module has been redefined.

There are some modules that Elixir does not currently implement but it may be implement in the future. Those modules are reserved and defining them will result in a compilation error:

defmodule Any do
  # code
end
#=> ** (CompileError) iex:1: module Any is reserved and cannot be defined

Elixir reserves the following module names: Elixir, Any, BitString, PID, and Reference.

Makes the given functions in the current module overridable.

An overridable function is lazily defined, allowing a developer to override it.

Example

defmodule DefaultMod do
  defmacro __using__(_opts) do
    quote do
      def test(x, y) do
        x + y
      end

      defoverridable test: 2
    end
  end
end

defmodule InheritMod do
  use DefaultMod

  def test(x, y) do
    x * y + super(x, y)
  end
end

As seen as in the example above, super can be used to call the default implementation.

If @behaviour has been defined, defoverridable can also be called with a module as an argument. All implemented callbacks from the behaviour above the call to defoverridable will be marked as overridable.

Example

defmodule Behaviour do
  @callback foo :: any
end

defmodule DefaultMod do
  defmacro __using__(_opts) do
    quote do
      @behaviour Behaviour

      def foo do
        "Override me"
      end

      defoverridable Behaviour
    end
  end
end

defmodule InheritMod do
  use DefaultMod

  def foo do
    "Overridden"
  end
end

Defines a private function with the given name and body.

Private functions are only accessible from within the module in which they are defined. Trying to access a private function from outside the module it's defined in results in an UndefinedFunctionError exception.

Check def/2 for more information.

Examples

defmodule Foo do
  def bar do
    sum(1, 2)
  end

  defp sum(a, b), do: a + b
end

Foo.bar()
#=> 3

Foo.sum(1, 2)
#=> ** (UndefinedFunctionError) undefined function Foo.sum/2

Defines a protocol.

A protocol specifies an API that should be defined by its implementations.

Examples

In Elixir, we have two verbs for checking how many items there are in a data structure: length and size. length means the information must be computed. For example, length(list) needs to traverse the whole list to calculate its length. On the other hand, tuple_size(tuple) and byte_size(binary) do not depend on the tuple and binary size as the size information is precomputed in the data structure.

Although Elixir includes specific functions such as tuple_size, binary_size and map_size, sometimes we want to be able to retrieve the size of a data structure regardless of its type. In Elixir we can write polymorphic code, i.e. code that works with different shapes/types, by using protocols. A size protocol could be implemented as follows:

defprotocol Size do
  @doc "Calculates the size (and not the length!) of a data structure"
  def size(data)
end

Now that the protocol can be implemented for every data structure the protocol may have a compliant implementation for:

defimpl Size, for: BitString do
  def size(binary), do: byte_size(binary)
end

defimpl Size, for: Map do
  def size(map), do: map_size(map)
end

defimpl Size, for: Tuple do
  def size(tuple), do: tuple_size(tuple)
end

Notice we didn't implement it for lists as we don't have the size information on lists, rather its value needs to be computed with length.

It is possible to implement protocols for all Elixir types:

• Structs (see below)
• Tuple
• Atom
• List
• BitString
• Integer
• Float
• Function
• PID
• Map
• Port
• Reference
• Any (see below)

Protocols and Structs

The real benefit of protocols comes when mixed with structs. For instance, Elixir ships with many data types implemented as structs, like MapSet. We can implement the Size protocol for those types as well:

defimpl Size, for: MapSet do
  def size(map_set), do: MapSet.size(map_set)
end

When implementing a protocol for a struct, the :for option can be omitted if the defimpl call is inside the module that defines the struct:

defmodule User do
  defstruct [:email, :name]

  defimpl Size do
    # two fields
    def size(%User{}), do: 2
  end
end

If a protocol implementation is not found for a given type, invoking the protocol will raise unless it is configured to fall back to Any. Conveniences for building implementations on top of existing ones are also available, look at defstruct/1 for more information about deriving protocols.

Fallback to Any

In some cases, it may be convenient to provide a default implementation for all types. This can be achieved by setting the @fallback_to_any attribute to true in the protocol definition:

defprotocol Size do
  @fallback_to_any true
  def size(data)
end

The Size protocol can now be implemented for Any:

defimpl Size, for: Any do
  def size(_), do: 0
end

Although the implementation above is arguably not a reasonable one. For example, it makes no sense to say a PID or an integer have a size of 0. That's one of the reasons why @fallback_to_any is an opt-in behaviour. For the majority of protocols, raising an error when a protocol is not implemented is the proper behaviour.

Multiple implementations

Protocols can also be implemented for multiple types at once:

defprotocol Reversible do
  def reverse(term)
end

defimpl Reversible, for: [Map, List] do
  def reverse(term), do: Enum.reverse(term)
end

Types

Defining a protocol automatically defines a type named t, which can be used as follows:

@spec print_size(Size.t()) :: :ok
def print_size(data) do
  result =
    case Size.size(data) do
      0 -> "data has no items"
      1 -> "data has one item"
      n -> "data has #{n} items"
    end

  IO.puts(result)
end

The @spec above expresses that all types allowed to implement the given protocol are valid argument types for the given function.

Reflection

Any protocol module contains three extra functions:

• __protocol__/1 - returns the protocol information. The function takes one of the following atoms:

  • :consolidated? - returns whether the protocol is consolidated

  • :functions - returns keyword list of protocol functions and their arities

  • :impls - if consolidated, returns {:consolidated, modules} with the list of modules implementing the protocol, otherwise :not_consolidated

  • :module - the protocol module atom name

• impl_for/1 - receives a structure and returns the module that implements the protocol for the structure, nil otherwise

• impl_for!/1 - same as above but raises an error if an implementation is not found

For example, for the Enumerable protocol we have:

iex> Enumerable.__protocol__(:functions)
[count: 1, member?: 2, reduce: 3, slice: 1]

iex> Enumerable.impl_for([])
Enumerable.List

iex> Enumerable.impl_for(42)
nil

Consolidation

In order to cope with code loading in development, protocols in Elixir provide a slow implementation of protocol dispatching specific to development.

In order to speed up dispatching in production environments, where all implementations are known up-front, Elixir provides a feature called protocol consolidation. Consolidation directly links protocols to their implementations in a way that invoking a function from a consolidated protocol is equivalent to invoking two remote functions.

Protocol consolidation is applied by default to all Mix projects during compilation. This may be an issue during test. For instance, if you want to implement a protocol during test, the implementation will have no effect, as the protocol has already been consolidated. One possible solution is to include compilation directories that are specific to your test environment in your mix.exs:

def project do
  ...
  elixirc_paths: elixirc_paths(Mix.env())
  ...
end

defp elixirc_paths(:test), do: ["lib", "test/support"]
defp elixirc_paths(_), do: ["lib"]

And then you can define the implementations specific to the test environment inside test/support/some_file.ex.

Another approach is to disable protocol consolidation during tests in your mix.exs:

def project do
  ...
  consolidate_protocols: Mix.env() != :test
  ...
end

Although doing so is not recommended as it may affect your test suite performance.

Finally note all protocols are compiled with debug_info set to true, regardless of the option set by elixirc compiler. The debug info is used for consolidation and it may be removed after consolidation.

Defines a struct.

A struct is a tagged map that allows developers to provide default values for keys, tags to be used in polymorphic dispatches and compile time assertions.

To define a struct, a developer must define both __struct__/0 and __struct__/1 functions. defstruct/1 is a convenience macro which defines such functions with some conveniences.

For more information about structs, please check Kernel.SpecialForms.%/2.

Examples

defmodule User do
  defstruct name: nil, age: nil
end

Struct fields are evaluated at compile-time, which allows them to be dynamic. In the example below, 10 + 11 is evaluated at compile-time and the age field is stored with value 21:

defmodule User do
  defstruct name: nil, age: 10 + 11
end

The fields argument is usually a keyword list with field names as atom keys and default values as corresponding values. defstruct/1 also supports a list of atoms as its argument: in that case, the atoms in the list will be used as the struct's field names and they will all default to nil.

defmodule Post do
  defstruct [:title, :content, :author]
end

Deriving

Although structs are maps, by default structs do not implement any of the protocols implemented for maps. For example, attempting to use a protocol with the User struct leads to an error:

john = %User{name: "John"}
MyProtocol.call(john)
** (Protocol.UndefinedError) protocol MyProtocol not implemented for %User{...}

defstruct/1, however, allows protocol implementations to be derived. This can be done by defining a @derive attribute as a list before invoking defstruct/1:

defmodule User do
  @derive [MyProtocol]
  defstruct name: nil, age: 10 + 11
end

MyProtocol.call(john) #=> works

For each protocol in the @derive list, Elixir will assert the protocol has been implemented for Any. If the Any implementation defines a __deriving__/3 callback, the callback will be invoked and it should define the implementation module. Otherwise an implementation that simply points to the Any implementation is automatically derived. For more information on the __deriving__/3 callback, see Protocol.derive/3.

Enforcing keys

When building a struct, Elixir will automatically guarantee all keys belongs to the struct:

%User{name: "john", unknown: :key}
** (KeyError) key :unknown not found in: %User{age: 21, name: nil}

Elixir also allows developers to enforce certain keys must always be given when building the struct:

defmodule User do
  @enforce_keys [:name]
  defstruct name: nil, age: 10 + 11
end

Now trying to build a struct without the name key will fail:

%User{age: 21}
** (ArgumentError) the following keys must also be given when building struct User: [:name]

Keep in mind @enforce_keys is a simple compile-time guarantee to aid developers when building structs. It is not enforced on updates and it does not provide any sort of value-validation.

Types

It is recommended to define types for structs. By convention such type is called t. To define a struct inside a type, the struct literal syntax is used:

defmodule User do
  defstruct name: "John", age: 25
  @type t :: %__MODULE__{name: String.t(), age: non_neg_integer}
end

It is recommended to only use the struct syntax when defining the struct's type. When referring to another struct it's better to use User.t instead of %User{}.

The types of the struct fields that are not included in %User{} default to term() (see term/0).

Structs whose internal structure is private to the local module (pattern matching them or directly accessing their fields should not be allowed) should use the @opaque attribute. Structs whose internal structure is public should use @type.

Destructures two lists, assigning each term in the right one to the matching term in the left one.

Unlike pattern matching via =, if the sizes of the left and right lists don't match, destructuring simply stops instead of raising an error.

Examples

iex> destructure([x, y, z], [1, 2, 3, 4, 5])
iex> {x, y, z}
{1, 2, 3}

In the example above, even though the right list has more entries than the left one, destructuring works fine. If the right list is smaller, the remaining items are simply set to nil:

iex> destructure([x, y, z], [1])
iex> {x, y, z}
{1, nil, nil}

The left-hand side supports any expression you would use on the left-hand side of a match:

x = 1
destructure([^x, y, z], [1, 2, 3])

The example above will only work if x matches the first value in the right list. Otherwise, it will raise a MatchError (like the = operator would do).

Specs

exit(term()) :: no_return()

Stops the execution of the calling process with the given reason.

Since evaluating this function causes the process to terminate, it has no return value.

Inlined by the compiler.

Examples

When a process reaches its end, by default it exits with reason :normal. You can also call exit/1 explicitly if you want to terminate a process but not signal any failure:

exit(:normal)

In case something goes wrong, you can also use exit/1 with a different reason:

exit(:seems_bad)

If the exit reason is not :normal, all the processes linked to the process that exited will crash (unless they are trapping exits).

OTP exits

Exits are used by the OTP to determine if a process exited abnormally or not. The following exits are considered "normal":

• exit(:normal)
• exit(:shutdown)
• exit({:shutdown, term})

Exiting with any other reason is considered abnormal and treated as a crash. This means the default supervisor behaviour kicks in, error reports are emitted, etc.

This behaviour is relied on in many different places. For example, ExUnit uses exit(:shutdown) when exiting the test process to signal linked processes, supervision trees and so on to politely shut down too.

CLI exits

Building on top of the exit signals mentioned above, if the process started by the command line exits with any of the three reasons above, its exit is considered normal and the Operating System process will exit with status 0.

It is, however, possible to customize the Operating System exit signal by invoking:

exit({:shutdown, integer})

This will cause the OS process to exit with the status given by integer while signaling all linked Erlang processes to politely shut down.

Any other exit reason will cause the OS process to exit with status 1 and linked Erlang processes to crash.

Specs

function_exported?(module(), atom(), arity()) :: boolean()

Returns true if module is loaded and contains a public function with the given arity, otherwise false.

Note that this function does not load the module in case it is not loaded. Check Code.ensure_loaded/1 for more information.

Inlined by the compiler.

Examples

iex> function_exported?(Enum, :member?, 2)
true

Gets a value and updates a nested data structure via the given path.

This is similar to get_and_update_in/3, except the path is extracted via a macro rather than passing a list. For example:

get_and_update_in(opts[:foo][:bar], &{&1, &1 + 1})

Is equivalent to:

get_and_update_in(opts, [:foo, :bar], &{&1, &1 + 1})

Note that in order for this macro to work, the complete path must always be visible by this macro. See the Paths section below.

Examples

iex> users = %{"john" => %{age: 27}, "meg" => %{age: 23}}
iex> get_and_update_in(users["john"].age, &{&1, &1 + 1})
{27, %{"john" => %{age: 28}, "meg" => %{age: 23}}}

Paths

A path may start with a variable, local or remote call, and must be followed by one or more:

• foo[bar] - accesses the key bar in foo; in case foo is nil, nil is returned

• foo.bar - accesses a map/struct field; in case the field is not present, an error is raised

Here are some valid paths:

users["john"][:age]
users["john"].age
User.all()["john"].age
all_users()["john"].age

Here are some invalid ones:

# Does a remote call after the initial value
users["john"].do_something(arg1, arg2)

# Does not access any key or field
users

Specs

get_and_update_in(
  structure :: Access.t(),
  keys,
  (term() -> {get_value, update_value} | :pop)
) :: {get_value, structure :: Access.t()}
when keys: [any(), ...], update_value: term(), get_value: var

Gets a value and updates a nested structure.

data is a nested structure (that is, a map, keyword list, or struct that implements the Access behaviour).

The fun argument receives the value of key (or nil if key is not present) and must return one of the following values:

• a two-element tuple {get_value, new_value}. In this case, get_value is the retrieved value which can possibly be operated on before being returned. new_value is the new value to be stored under key.

• :pop, which implies that the current value under key should be removed from the structure and returned.

This function uses the Access module to traverse the structures according to the given keys, unless the key is a function.

If a key is a function, the function will be invoked passing three arguments:

• the operation (:get_and_update)
• the data to be accessed
• a function to be invoked next

This means get_and_update_in/3 can be extended to provide custom lookups. The downside is that functions cannot be stored as keys in the accessed data structures.

Examples

This function is useful when there is a need to retrieve the current value (or something calculated in function of the current value) and update it at the same time. For example, it could be used to read the current age of a user while increasing it by one in one pass:

iex> users = %{"john" => %{age: 27}, "meg" => %{age: 23}}
iex> get_and_update_in(users, ["john", :age], &{&1, &1 + 1})
{27, %{"john" => %{age: 28}, "meg" => %{age: 23}}}

When one of the keys is a function, the function is invoked. In the example below, we use a function to get and increment all ages inside a list:

iex> users = [%{name: "john", age: 27}, %{name: "meg", age: 23}]
iex> all = fn :get_and_update, data, next ->
...>   data |> Enum.map(next) |> Enum.unzip()
...> end
iex> get_and_update_in(users, [all, :age], &{&1, &1 + 1})
{[27, 23], [%{name: "john", age: 28}, %{name: "meg", age: 24}]}

If the previous value before invoking the function is nil, the function will receive nil as a value and must handle it accordingly (be it by failing or providing a sane default).

The Access module ships with many convenience accessor functions, like the all anonymous function defined above. See Access.all/0, Access.key/2, and others as examples.

Specs

get_in(Access.t(), [term(), ...]) :: term()

Gets a value from a nested structure.

Uses the Access module to traverse the structures according to the given keys, unless the key is a function.

If a key is a function, the function will be invoked passing three arguments:

• the operation (:get)
• the data to be accessed
• a function to be invoked next

This means get_in/2 can be extended to provide custom lookups. The downside is that functions cannot be stored as keys in the accessed data structures.

Examples

iex> users = %{"john" => %{age: 27}, "meg" => %{age: 23}}
iex> get_in(users, ["john", :age])
27

In case any of the entries in the middle returns nil, nil will be returned as per the Access module:

iex> users = %{"john" => %{age: 27}, "meg" => %{age: 23}}
iex> get_in(users, ["unknown", :age])
nil

When one of the keys is a function that takes three arguments, the function is invoked. In the example below, we use a function to get all the maps inside a list:

iex> users = [%{name: "john", age: 27}, %{name: "meg", age: 23}]
iex> all = fn :get, data, next -> Enum.map(data, next) end
iex> get_in(users, [all, :age])
[27, 23]

If the previous value before invoking the function is nil, the function will receive nil as a value and must handle it accordingly.

Provides an if/2 macro.

This macro expects the first argument to be a condition and the second argument to be a keyword list.

One-liner examples

if(foo, do: bar)

In the example above, bar will be returned if foo evaluates to a truthy value (neither false nor nil). Otherwise, nil will be returned.

An else option can be given to specify the opposite:

if(foo, do: bar, else: baz)

Blocks examples

It's also possible to pass a block to the if/2 macro. The first example above would be translated to:

if foo do
  bar
end

Note that do/end become delimiters. The second example would translate to:

if foo do
  bar
else
  baz
end

In order to compare more than two clauses, the cond/1 macro has to be used.

Specs

inspect(Inspect.t(), keyword()) :: String.t()

Inspects the given argument according to the Inspect protocol. The second argument is a keyword list with options to control inspection.

Options

inspect/2 accepts a list of options that are internally translated to an Inspect.Opts struct. Check the docs for Inspect.Opts to see the supported options.

Examples

iex> inspect(:foo)
":foo"

iex> inspect([1, 2, 3, 4, 5], limit: 3)
"[1, 2, 3, ...]"

iex> inspect([1, 2, 3], pretty: true, width: 0)
"[1,\n 2,\n 3]"

iex> inspect("olá" <> <<0>>)
"<<111, 108, 195, 161, 0>>"

iex> inspect("olá" <> <<0>>, binaries: :as_strings)
"\"olá\\0\""

iex> inspect("olá", binaries: :as_binaries)
"<<111, 108, 195, 161>>"

iex> inspect('bar')
"'bar'"

iex> inspect([0 | 'bar'])
"[0, 98, 97, 114]"

iex> inspect(100, base: :octal)
"0o144"

iex> inspect(100, base: :hex)
"0x64"