1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
|
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE chapter SYSTEM "chapter.dtd">
<chapter>
<header>
<copyright>
<year>2022</year><year>2023</year>
<holder>Ericsson AB. All Rights Reserved.</holder>
</copyright>
<legalnotice>
Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
</legalnotice>
<title>Features</title>
<prepared></prepared>
<docno></docno>
<date></date>
<rev></rev>
<file>features.xml</file>
</header>
<p>
<marker id="features"/>
Introduced in OTP 25, Erlang has the concept of selectable features.
A feature can change, add or remove behaviour of the language and/or
runtime system. Examples can include
</p>
<list>
<item>Adding new syntactical constructs to the language</item>
<item>Change the semantics of an existing construct</item>
<item>Change the behaviour of some runtime aspect</item>
</list>
<p>
A feature will start out with a status of experimental part of OTP,
making it possible to try out for users and give feedback. The
possibility to try out features is enabled by options to the
compiler, directives in a module and options to the runtime system.
Even when a feature is not experimental it will still be possible to
enable or disable it. This makes it possible to adapt a code base
at a suitable pace instead of being forced when changing to a new
release.
</p>
<p>
The status of a feature will eventually end up as being either a
permanent part of OTP or rejected, being removed and no longer
selectable.
</p>
<section>
<title>Life cycle of features</title>
<p>A feature is in one of four possible states:</p>
<taglist>
<tag>Experimental</tag>
<item>The initial state, is meant for trying out and collecting
feedback. The feature can be enabled but is disabled by
default.</item>
<tag>Approved</tag>
<item>The feature has been finalised and is now part of OTP. By
default it is enabled, but can be disabled.</item>
<tag>Permanent</tag>
<item>The feature is now a permanent part of OTP. It can no
longer be disabled.</item>
<tag>Rejected</tag>
<item>The feature never reached the approved state and will not
be part of OTP. It cannot be enabled.</item>
</taglist>
<p>
After leaving the experimental state, a feature can enter any of
the other three states, and if the next state is approved, the
feature will eventually end up in the permanent state. A feature
can change state only in connection with a release.
</p>
<p>
A feature may be in the approved state for several releases.
</p>
<table>
<row>
<cell>State</cell>
<cell>Default</cell>
<cell>Configurable</cell>
<cell>Available</cell>
</row>
<row>
<cell>Experimental</cell>
<cell>disabled</cell>
<cell>yes</cell>
<cell>yes</cell>
</row>
<row>
<cell>Approved</cell>
<cell>enabled</cell>
<cell>yes</cell>
<cell>yes</cell>
</row>
<row>
<cell>Permanent</cell>
<cell>enabled</cell>
<cell>no</cell>
<cell>yes</cell>
</row>
<row>
<cell>Rejected</cell>
<cell>disabled</cell>
<cell>no</cell>
<cell>no</cell>
</row>
<tcaption>Feature States</tcaption>
</table>
<list>
<item>Being configurable means the possibility to enable or
disable the feature by means of compiler options and directives
in the file being compiled.</item>
<item>Being available can be seen using the
<c>FEATURE_AVAILABLE</c> macro.</item>
</list>
</section>
<section>
<title>Enabling and Disabling Features</title>
<p>To use a feature that is in the experimental state, it has to
be enabled during compilation. This can be done in a number of
different ways:
</p>
<taglist>
<tag>Options to <c>erlc</c></tag>
<item>Options <seecom
marker="erts:erlc#enable-feature"><c>-enable-feature</c></seecom>
and <seecom
marker="erts:erlc#disable-feature"><c>-disable-feature</c></seecom>
can be used to enable or disable individal features.</item>
<tag>Compiler options</tag>
<item>The compiler option <seeerl
marker="compiler:compile#feature-option"><c>{feature,
<feature>, enable|disable}</c></seeerl> can be used either
as a <c>+<term></c> option to <c>erlc</c> or in the options
argument to functions in the <c>compile</c> module.</item>
<tag>The feature directive</tag>
<item>Inside a prefix of a module, one can use a <seeguide
marker="macros#feature-directive"><c>-feature(<feature>,
enable|disable)</c></seeguide> directive. This is the preferred
method of enabling and disabling features.</item>
</taglist>
<change>
<p>In Erlang/OTP 25, in order to load a module with a feature
enabled, it was necessary to also enable the feature in the runtime.
This was done using option <seecom
marker="erts:erl#enable-feature"><c>-enable-feature</c></seecom> to
<c>erl</c>. This requirement was removed in Erlang/OTP 26.</p>
</change>
</section>
<section>
<title>Preprocessor Additions</title>
<p>
To allow for conditional compilation during transitioning of a
code base and/or trying out experimental features <seeguide
marker="system/reference_manual:macros#predefined-macros">feature</seeguide>
<c>predefined macros</c> <c>?FEATURE_AVAILABLE(Feature)</c> and
<c>?FEATURE_ENABLED(Feature)</c> are available.
</p>
</section>
<section>
<title>Information about Existing Features</title>
<p>
The module <c>erl_features</c> <seeerl
marker="stdlib:erl_features"><c>erl_features</c></seeerl> exports
a number of functions that can be used to obtain information about
current features as well as the features used when compiling a
module.
</p>
<p>One can also use the <c>erlc</c> options <seecom
marker="erts:erlc#list-features"><c>-list-features</c></seecom>
and <seecom
marker="erts:erlc#describe-feature"><c>-describe-feature
<feature></c></seecom> to get information about existing
features.
</p>
<p>
Additionally, there is the compiler option
<seeerl
marker="compiler:compile#warn-keywords"><c>warn_keywords</c></seeerl>
that can be used to find atoms in the code base that might
collide with keywords in features not yet enabled.
</p>
</section>
<section>
<title>Existing Features</title>
<p>
The following configurable features exist:
</p>
<taglist>
<tag><c>maybe_expr</c> (experimental)</tag>
<item>
Implementation of the <seeguide
marker="expressions#maybe"><c>maybe</c></seeguide> expression
proposed in <url href="https://www.erlang.org/eeps/eep-0049">EEP 49</url>.</item>
</taglist>
</section>
</chapter>
|
