4 Upcoming Potential Incompatibilities

4.1 Introduction

This document lists planned upcoming potential incompatibilities in Erlang/OTP.

4.2 OTP 25

Distribution flags will become mandatory

In OTP 25, more distribution flags will become mandatory. That is, Erlang nodes will refuse to connect to nodes not implementing all of the mandatory distribution flags. If you implement the Erlang distribution protocol yourself, you will need to implement support for all mandatory distribution flags in order to communicate with Erlang nodes running OTP 25.

The following distribution flags will become mandatory in OTP 25:

DFLAG_BIT_BINARIES: Support for bitstrings.
DFLAG_EXPORT_PTR_TAG: Support for external funs (fun Module:Name/Arity).
DFLAG_MAP_TAGS: Support for maps.
DFLAG_NEW_FLOATS: Support for the new encoding of floats.
DFLAG_FUN_TAGS: Support for funs, but only in the new format (NEW_FUN_EXT) because DFLAG_NEW_FUN_TAGS is also mandatory.

4.3 OTP 26

The distribution flag DFLAG_V4_NC will become mandatory

As of OTP 26, the distribution flag DFLAG_V4_NC will become mandatory. If you implement the Erlang distribution protocol yourself, you will need to implement support for DFLAG_V4_NC in order to communicate with Erlang nodes running OTP 26.

The new link protocol will become mandatory

As of OTP 26, the new link protocol will become mandatory. That is, Erlang nodes will then refuse to connect to nodes not implementing the new link protocol. If you implement the Erlang distribution yourself, you are, however, encouraged to implement the new link protocol as soon as possible since the old protocol can cause links to enter an inconsistent state.

Atoms will be encoded as UTF-8 by default

As of OTP 26, the functions erlang:term_to_binary/1,2 and erlang:term_to_iovec/1,2 will encode all atoms as UTF-8 by default. The current default behavior is to encode atoms as Latin-1 if possible.

If you implement your own decoding of the Erlang external format you must either:

Make sure your implementation supports the UTF-8 encodings ATOM_UTF8_EXT and SMALL_ATOM_UTF8_EXT.
Call erlang:term_to_binary/2 or erlang:term_to_iovec/2 with option {minor_version,1} to force Latin-1 encoding. This is a more short-term solution as Latin-1 encoding may be phased out and removed in later OTP releases.

4.4 OTP 27

Fun creator pid will be removed

As of OTP 27, the functions erlang:fun_info/1,2 will always say that the local init process created all funs, regardless of which process or node the fun was originally created on.

In OTP 28, the {pid,_}element will be removed altogether.

The re module will use a different regular expression engine

The functionality of module re is currently provided by the PCRE library, which is no longer actively maintained. Therefore, in OTP 28, we will switch to a different regular expression library.

The source code for PCRE used by the re module has been modified by the OTP team to ensure that a regular expression match would yield when matching huge input binaries and/or when using demanding (back-tracking) regular expressions. Because of the those modifications, moving to a new version of PCRE has always been a time-consuming process because all of the modifications had to be applied by hand again to the updated PCRE source code.

Most likely, the new regular expression library will be RE2. RE2 guarantees that the match time is linear in the length of input string, and it also eschews recursion to avoid stack overflow. That should make it possible to use RE2 without modifying its source code. For more information about why RE2 is a good choice, see WhyRE2.

Some of implications of this change are:

We expect that the functions in the re module will continue to be supported, although some of the options are likely to be dis-continued.
It is likely that only pattern matching of UTF8-encoded binaries will be supported (not Latin1-encoded binaries).
In order to guarantee the linear-time performance, RE2 does not support all the constructs in regular expression patterns that PCRE do. For example, backreferences and look-around assertions are not supported. See Syntax for a description of what RE2 supports.
Compiling a regular expression is likely to be slower, and thus more can be gained by explicitly compiling the regular expression before matching with it.

Triple-Quoted Strings

Before Erlang/OTP 27 a sequence of 3 or more double-quote characters was grouped in pairs each meaning the empty string and if there was an odd number the last character was the start of a string. The empty strings were then concatenated and effectively disappeared.

In Erlang/OTP 27; 3 or more double-quote characters are interpreted as the start of a "Triple-Quoted String". See EEP 64.

Here follows some examples of code that would change meaning. Note that all these examples before Erlang/OTP 27.0 was strange since there was no sensible reason to write like that.

"""String Content"""
%% Was interpreted as
"" "String Content" ""
%% Which becomes
"String Content"
%%
%% In OTP 27 it is instead a syntax error since no text is allowed
%% on the line after an opening triple-quote

"""
String Content
"""
%% Was interpreted as
"" "
String Content
" ""
%% Which becomes
"
String Content
"
%%
%% In OTP 27 it is instead interpreted as a
%% Triple-Quoted String equivalent to
"String Content"

""""
++ foo() ++
""""
%% Became
"" ++ foo() ++ ""
%%
%% In OTP 27 it is instead interpreted as a
%% Triple-Quoted String (triple-or-more) equivalent to
"++ foo() ++"

From Erlang/OTP 26.1 up to 27.0 the compiler issues a warning for a sequence of 3 or more double-quote characters since that is almost certainly a mistake or something like a result of bad automatic code generation. If a users gets that warning, the code should be corrected for example by inserting appropriate spaces between the empty strings, or removing the redundant ones alltogether, which will have the same meaning before and after Erlang/OTP 27.

4.5 4.6 OTP 29

cprof and eprof will be replaced by tprof

As of OTP 29, the cprof and eprof will be removed in favor of tprof added in OTP 27.