|
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