20222022
Ericsson AB. All Rights Reserved.
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.
Features
features.xml
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
- Adding new syntactical constructs to the language
- Change the semantics of an existing construct
- Change the behaviour of some runtime aspect
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.
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.
Life cycle of features
A feature is in one of four possible states:
Experimental
- The initial state, is meant for trying out and collecting
feedback. The feature can be enabled but is disabled by
default.
Approved
- The feature has been finalised and is now part of OTP. By
default it is enabled, but can be disabled.
Permanent
- The feature is now a permanent part of OTP. It can no
longer be disabled.
Rejected
- The feature never reached the approved state and will not
be part of OTP. It cannot be enabled.
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.
A feature may be in the approved state for several releases.
| State |
Default |
Configurable |
Available |
| Experimental |
disabled |
yes |
yes |
| Approved |
enabled |
yes |
yes |
| Permanent |
enabled |
no |
yes |
| Rejected |
disabled |
no |
no |
Feature States
- Being configurable means the possibility to enable or
disable the feature by means of compiler options and directives
in the file being compiled.
- Being available can be seen using the
FEATURE_AVAILABLE macro.
Enabling and Disabling Features
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:
Options to erlc
- Options -enable-feature
and -disable-feature
can be used to enable or disable individal features.
Compiler options
- The compiler option {feature,
<feature>, enable|disable} can be used either
as a +<term> option to erlc, in the options
argument to function in the compile module, or in the
-compile(..) attribute in a file.
The feature directive
- Inside a prefix of a module, one can use a -feature(<feature>,
enable|disable) directive. This is the preferred
method of enabling and disabling features.
Note that to load a module compiled with features enabled, the
corresponding features must be enabled in the runtime. This
is done using options -enable-feature
and -disable-feature
to erl. This is to allow the possibility to prevent
the use of experimental features in, e.g., production. This
will catch experimental features used in both own and third
party components. An active choice to use experimental
features must be done.
Preprocessor Additions
To allow for conditional compilation during transitioning of a
code base and/or trying out experimental features feature
predefined macros ?FEATURE_AVAILABLE(Feature) and
?FEATURE_ENABLED(Feature) are available.
Information about Existing Features
The module erl_features erl_features 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.
One can also use the erlc options -list-features
and -describe-feature
<feature> to get information about existing
features.
Additionally, there is the compiler option
warn_keywords
that can be used to find atoms in the code base that might
collide with keywords in features not yet enabled.
Existing Features
The following configurable features exist:
maybe_expr (experimental)
-
Implementation of the maybe expression
proposed in EEP 49.