|
1 | 1 | defmodule Kernel.Typespec do
|
2 |
| - @moduledoc ~S""" |
3 |
| - Provides macros and functions for working with typespecs. |
4 |
| -
|
5 |
| - Elixir comes with a notation for declaring types and specifications. Elixir is |
6 |
| - dynamically typed, and as such, typespecs are never used by the compiler to |
7 |
| - optimize or modify code. Still, using typespecs is useful as documentation and |
8 |
| - tools such as [Dialyzer](http://www.erlang.org/doc/man/dialyzer.html) can |
9 |
| - analyze code with typespecs to find bugs. |
10 |
| -
|
11 |
| - The attributes `@type`, `@opaque`, `@typep`, `@spec`, `@callback` and |
12 |
| - `@macrocallback` available in modules are handled by the equivalent macros |
13 |
| - defined by this module. See sub-sections "Defining a type" and "Defining a |
14 |
| - specification" below. |
15 |
| -
|
16 |
| - ## Types and their syntax |
17 |
| -
|
18 |
| - The type syntax provided by Elixir is fairly similar to [the one in |
19 |
| - Erlang](http://www.erlang.org/doc/reference_manual/typespec.html). |
20 |
| -
|
21 |
| - Most of the built-in types provided in Erlang (for example, `pid()`) are |
22 |
| - expressed the same way: `pid()` or simply `pid`. Parameterized types are also |
23 |
| - supported (`list(integer)`) and so are remote types (`Enum.t`). |
24 |
| -
|
25 |
| - Integers and atom literals are allowed as types (ex. `1`, `:atom` or |
26 |
| - `false`). All other types are built of unions of predefined types. Certain |
27 |
| - shorthands are allowed, such as `[...]`, `<<>>` and `{...}`. |
28 |
| -
|
29 |
| - ### Basic types |
30 |
| -
|
31 |
| - type :: any() # the top type, the set of all terms |
32 |
| - | none() # the bottom type, contains no terms |
33 |
| - | pid() |
34 |
| - | port() |
35 |
| - | reference() |
36 |
| - | tuple() |
37 |
| - | atom() |
38 |
| - | integer() |
39 |
| - | non_neg_integer() # 0, 1, 2, 3, ... |
40 |
| - | pos_integer() # 1, 2, 3, ... |
41 |
| - | neg_integer() # ..., -3, -2, -1 |
42 |
| - | float() |
43 |
| - | map() |
44 |
| - | struct() |
45 |
| - | list(type) |
46 |
| - | nonempty_list(type) |
47 |
| - | improper_list(type1, type2) |
48 |
| - | maybe_improper_list(type1, type2) |
49 |
| - | Literals # Described in section "Literals" |
50 |
| - | Builtin # Described in section "Builtin-types" |
51 |
| - | Remotes # Described in section "Remotes" |
52 |
| -
|
53 |
| - ### Literals |
54 |
| -
|
55 |
| - The following literals are also supported in typespecs: |
56 |
| -
|
57 |
| - type :: :atom ## Atoms |
58 |
| - | 1 ## Integers |
59 |
| - | 1..10 ## Integers from 1 to 10 |
60 |
| - | 1.0 ## Floats |
61 |
| -
|
62 |
| - | <<>> ## Bitstrings |
63 |
| - | <<_::size>> # size is 0 or a positive integer |
64 |
| - | <<_::_ * unit>> # unit is an integer from 1 to 256 |
65 |
| - | <<_::size * unit>> |
66 |
| -
|
67 |
| - | [type] ## Lists |
68 |
| - | [] # empty list |
69 |
| - | [...] # shorthand for nonempty_list(any()) |
70 |
| - | [type, ...] # shorthand for nonempty_list(type) |
71 |
| - | [key: type] # keyword lists |
72 |
| -
|
73 |
| - | (... -> type) ## Functions |
74 |
| - | (... -> type) # any arity, returns type |
75 |
| - | (() -> type) # 0-arity, returns type |
76 |
| - | (type1, type2 -> type) # 2-arity, returns type |
77 |
| -
|
78 |
| - | %{} ## Maps |
79 |
| - | %{key: type} # map with key :key with value of type |
80 |
| - | %{type1 => type2} # map with keys of type1 with values of type2 |
81 |
| - | %SomeStruct{} |
82 |
| - | %SomeStruct{key: type} |
83 |
| -
|
84 |
| - | {} ## Tuples |
85 |
| - | {:ok, type} # two element tuple with an atom and any type |
86 |
| -
|
87 |
| - ### Built-in types |
88 |
| -
|
89 |
| - These types are also provided by Elixir as shortcuts on top of the |
90 |
| - basic and literal types. |
91 |
| -
|
92 |
| - Built-in type | Defined as |
93 |
| - :---------------------- | :--------- |
94 |
| - `term()` | `any()` |
95 |
| - `binary()` | `<<_::_ * 8>>` |
96 |
| - `bitstring()` | `<<_::_ * 1>>` |
97 |
| - `boolean()` | `false` \| `true` |
98 |
| - `byte()` | `0..255` |
99 |
| - `char()` | `0..0x10ffff` |
100 |
| - `number()` | `integer()` \| `float()` |
101 |
| - `char_list()` | `[char()]` |
102 |
| - `list()` | `[any()]` |
103 |
| - `maybe_improper_list()` | `maybe_improper_list(any(), any())` |
104 |
| - `nonempty_list()` | `nonempty_list(any())` |
105 |
| - `iodata()` | `iolist()` \| `binary()` |
106 |
| - `iolist()` | `maybe_improper_list(byte()` \| `binary()` \| `iolist(), binary()` \| `[])` |
107 |
| - `module()` | `atom()` \| `tuple()` |
108 |
| - `arity()` | `0..255` |
109 |
| - `mfa()` | `{atom(), atom(), arity()}` |
110 |
| - `node()` | `atom()` |
111 |
| - `timeout()` | `:infinity` \| `non_neg_integer()` |
112 |
| - `no_return()` | `none()` |
113 |
| - `fun()` | `(... -> any)` |
114 |
| - `struct()` | `%{__struct__: atom()}` |
115 |
| - `as_boolean(t)` | `t` |
116 |
| -
|
117 |
| - ### Remote types |
118 |
| -
|
119 |
| - Any module is also able to define its own type and the modules in |
120 |
| - Elixir are no exception. For example, a string is `String.t`, a |
121 |
| - range is `Range.t`, any enumerable can be `Enum.t` and so on. |
122 |
| -
|
123 |
| - ## Defining a type |
124 |
| -
|
125 |
| - @type type_name :: type |
126 |
| - @typep type_name :: type |
127 |
| - @opaque type_name :: type |
128 |
| -
|
129 |
| - A type defined with `@typep` is private. An opaque type, defined with |
130 |
| - `@opaque` is a type where the internal structure of the type will not be |
131 |
| - visible, but the type is still public. |
132 |
| -
|
133 |
| - Types can be parameterized by defining variables as parameters, these variables |
134 |
| - can then be used to define the type. |
135 |
| -
|
136 |
| - @type dict(key, value) :: [{key, value}] |
137 |
| -
|
138 |
| - ## Defining a specification |
139 |
| -
|
140 |
| - @spec function_name(type1, type2) :: return_type |
141 |
| - @callback function_name(type1, type2) :: return_type |
142 |
| - @macrocallback macro_name(type1, type2) :: Macro.t |
143 |
| -
|
144 |
| - Callbacks are used to define the callbacks functions of behaviours (see |
145 |
| - `Behaviour`). |
146 |
| -
|
147 |
| - Guards can be used to restrict type variables given as arguments to the |
148 |
| - function. |
149 |
| -
|
150 |
| - @spec function(arg) :: [arg] when arg: atom |
151 |
| -
|
152 |
| - Type variables with no restriction can also be defined. |
153 |
| -
|
154 |
| - @spec function(arg) :: [arg] when arg: var |
155 |
| -
|
156 |
| - Specifications can be overloaded just like ordinary functions. |
157 |
| -
|
158 |
| - @spec function(integer) :: atom |
159 |
| - @spec function(atom) :: integer |
160 |
| -
|
161 |
| - ## Notes |
162 |
| -
|
163 |
| - Elixir discourages the use of type `string` as it might be confused with |
164 |
| - binaries which are referred to as "strings" in Elixir (as opposed to character |
165 |
| - lists). In order to use the type that is called `string` in Erlang, one has to |
166 |
| - use the `char_list` type which is a synonym for `string`. If you use `string`, |
167 |
| - you'll get a warning from the compiler. |
168 |
| -
|
169 |
| - If you want to refer to the "string" type (the one operated on by functions in |
170 |
| - the `String` module), use `String.t` type instead. |
171 |
| - """ |
| 2 | + @moduledoc false |
172 | 3 |
|
173 | 4 | @doc """
|
174 | 5 | Defines a type.
|
|
0 commit comments