Operators

Attribute selection

attrset . attrpath [ or expr ]

Select the attribute denoted by attribute path attrpath from attribute set attrset. If the attribute doesn’t exist, return the expr after or if provided, otherwise abort evaluation.

An attribute path is a dot-separated list of attribute names.

attrpath = name [ . name ]...

Has attribute

attrset ? attrpath

Test whether attribute set attrset contains the attribute denoted by attrpath. The result is a Boolean value.

Arithmetic

Numbers will retain their type unless mixed with other numeric types: Pure integer operations will always return integers, whereas any operation involving at least one floating point number returns a floating point number.

Integer overflow (of 64-bit signed integers) and division by zero are defined to throw an error.

See also Comparison and Equality.

The + operator is overloaded to also work on strings and paths.

String concatenation

string + string

Concatenate two strings and merge their string contexts.

Path concatenation

path + path

Concatenate two paths. The result is a path.

Path and string concatenation

path + string

Concatenate path with string. The result is a path.

Note

The string must not have a string context that refers to a store path.

String and path concatenation

string + path

Concatenate string with path. The result is a string.

Important

The file or directory at path must exist and is copied to the store. The path appears in the result as the corresponding store path.

Update

attrset1 // attrset2

Update attribute set attrset1 with names and values from attrset2.

The returned attribute set will have of all the attributes in attrset1 and attrset2. If an attribute name is present in both, the attribute value from the latter is taken.

Comparison

Comparison is

• arithmetic for numbers
• lexicographic for strings and paths
• item-wise lexicographic for lists: elements at the same index in both lists are compared according to their type and skipped if they are equal.

All comparison operators are implemented in terms of <, and the following equivalencies hold:

Note that the above behaviour violates IEEE 754 for floating point numbers with respect to NaN, for instance. This may be fixed in a future major language revision.

Equality

The following equality comparison rules are followed in order:

• Comparisons are first, sometimes, performed by identity (pointer value), and whether or not this occurs varies depending on the context in which the comparison is performed; for example, through builtins.elem, comparison of lists, or other cases. The exact instances in which this occurs, aside from direct list and attribute set comparisons as discussed below, are too dependent on implementation details to meaningfully document.

  See note on identity comparison below.

• Comparisons between a combination of integers and floating point numbers are first converted to floating point then compared as floating point.

• Comparisons between values of differing types, besides the ones mentioned in the above rule, are unequal.

• Strings are compared as their string values, disregarding string contexts.

• Paths are compared as their absolute form (since they are stored as such).

• Functions are always considered unequal, including with themselves.

• The following are compared in the typical manner:

  • Integers

  • Floating point numbers have equality comparison per IEEE 754.

    Note that this means that just like in most languages, floating point arithmetic results are not typically equality comparable, and should instead be compared by checking that the absolute difference is less than some error margin.

  • Booleans

  • Null

• Attribute sets are compared following these rules in order:

  • If both attribute sets have the same identity (via pointer equality), they are considered equal, regardless of whether the contents have reflexive equality (e.g. even if there are functions contained within).

    See note on identity comparison below.

  • If both attribute sets have type = "derivation" and have an attribute outPath that is equal, they are considered equal.

    This means that two results of builtins.derivation, regardless of other things added to their attributes via // afterwards (or passthru in nixpkgs), will compare equal if they passed the same arguments to builtins.derivation.

  • Otherwise, they are compared element-wise in an unspecified order. Although this order may be deterministic in some cases, this is not guaranteed, and correct code must not rely on this ordering behaviour.

    The order determines which elements are evaluated first and thus, if there are throwing values in the attribute set, which of those get evaluated, if any, before the comparison returns an unequal result.

• Lists are compared following these rules in order:

  • If both lists have the same identity (via pointer equality), they are considered equal, regardless of whether the contents have reflexive equality (e.g. even if there are functions contained within).

    See note on identity comparison below.

  • Otherwise, they are compared element-wise in list order.

Identity comparison

In the current revision of the Nix language, values are first compared by identity (pointer equality). This means that values that are not reflexively equal (that is, they do not satisfy a == a), such as functions, are nonetheless sometimes compared as equal with themselves if they are placed in attribute sets or lists, or are compared through other indirect means.

Whether identity comparison applies to a given usage of the language aside from direct list and attribute set comparison is strongly dependent on implementation details to the point it is not feasible to document the exact instances.

This is rather unfortunate behaviour which is regrettably load-bearing on nixpkgs (such as with the type attribute of NixOS options) and cannot be changed for the time being. It may be changed in a future major language revision.

Correct code must not rely on this behaviour.

For example:

nix-repl> let f = x: 1; s = { func = f; }; in [ (f == f) (s == s) ]
[ false true ]

Logical implication

Equivalent to !b1 || b2.

[Experimental] Function piping

This language feature is still experimental and may change at any time. Enable --extra-experimental-features pipe-operator to use it.

Pipes are a dedicated operator for function application, but with reverse order and a lower binding strength. This allows you to chain function calls together in way that is more natural to read and requires less parentheses.

a |> f b |> g is equivalent to g (f b a). g <| f b <| a is equivalent to g (f b a).

Example code snippet:

defaultPrefsFile = defaultPrefs
  |> lib.mapAttrsToList (
    key: value: ''
      // ${value.reason}
      pref("${key}", ${builtins.toJSON value.value});
    ''
  )
  |> lib.concatStringsSep "\n"
  |> pkgs.writeText "nixos-default-prefs.js";

Note how mapAttrsToList is called with two arguments (the lambda and defaultPrefs), but moving the last argument in front of the rest improves the reading flow. This is common for functions with long first argument, including all map-like functions.