Erlang -- Upcoming Potential Incompatibilities

# 4 Upcoming Potential Incompatibilities

###
4.1 Introduction

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

###
4.2 OTP 27

####
Fun creator pid will always be local init process

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.

####
Feature maybe_expr will be enabled by default

As of OTP 27, the maybe_expr feature will be approved and enabled by default. That means that code that uses the unquoted atom maybe will fail to compile. All uses of maybe as an atom will need to be quoted. Alternatively, as a short-term solution, the maybe_expr feature can be disabled.

It is recommend to quote all uses of the atom maybe as soon as possible. The compiler option warn_keywords can be used to emit warnings about all occurrences of maybe without quotes.

####
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 27, 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.

####
0.0 and -0.0 will no longer be exactly equal

Currently, the floating point numbers 0.0 and -0.0 have distinct internal representations. That can be seen if they are converted to binaries:

    1> <<0.0/float>>.
    <<0,0,0,0,0,0,0,0>>
    2> <<-0.0/float>>.
    <<128,0,0,0,0,0,0,0>>

However, when they are matched against each other or compared using the =:= operator, they are considered to be equal. Thus, 0.0 =:= -0.0 currently returns true.

In Erlang/OTP 27, 0.0 =:= -0.0 will return false, and matching 0.0 against -0.0 will fail. When used as map keys, 0.0 and -0.0 will be considered to be distinct.

The == operator will continue to return true for 0.0 == -0.0.

To help to find code that might need to be revised, in OTP 27 there will be a new compiler warning when matching against 0.0 or comparing to that value using the =:= operator. The warning can be suppressed by matching against +0.0 instead of 0.0.

We plan to introduce the same warning in OTP 26.1, but by default it will be disabled.

####
Singleton type variables will become a compile-time error

Before Erlang/OTP 26, the compiler would silenty accept the following spec:

    -spec f(Opts) -> term() when
        Opts :: {ok, Unknown} | {error, Unknown}.
    f(_) -> error.

In OTP 26, the compiler emits a warning pointing out that the type variable Unknown is unbound:

    t.erl:6:18: Warning: type variable 'Unknown' is only used once (is unbound)
    %    6|     Opts :: {ok, Unknown} | {error, Unknown}.
    %     |                  ^

In OTP 27, that warning will become an error.

###
4.3 OTP 28

####
Fun creator pid will be removed

As of OTP 28, the function erlang:fun_info/1 will not include the {pid,_} element and the function erlang:fun_info/2 will no longer accept pid as the second argument.

###
4.4 OTP 29

####
It will no longer be possible to disable feature maybe_expr

As of OTP 29, the maybe_expr feature will become permanent and no longer possible to disable. All uses of maybe as an atom will need to be quoted.

It is recommend to quote all uses of the atom maybe as soon as possible. The compiler option warn_keywords can be used to emit warnings about all occurrences of maybe without quotes.