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
212
213
214
215
216
217
|
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE chapter SYSTEM "chapter.dtd">
<chapter>
<header>
<copyright>
<year>2021</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>Upcoming Potential Incompatibilities</title>
<prepared></prepared>
<docno></docno>
<date></date>
<rev></rev>
<file>upcoming_incompatibilities.xml</file>
</header>
<section>
<title>Introduction</title>
<p>This document lists planned upcoming potential incompatibilities in
Erlang/OTP.</p>
</section>
<section>
<title>OTP 27</title>
<section>
<marker id="fun_creator_pid"/>
<title>Fun creator pid will always be local init process</title>
<p>
As of OTP 27, the functions
<seemfa marker="erts:erlang#fun_info/1">
<c>erlang:fun_info/1,2</c></seemfa> will always say that the local
<c>init</c> process created all funs, regardless of which process or
node the fun was originally created on.
</p>
<p>
In OTP 28, the <c>{pid,_}</c>element will be removed altogether.</p>
</section>
<section>
<marker id="maybe_expr"/>
<title>Feature maybe_expr will be enabled by default</title>
<p>
As of OTP 27, the <c>maybe_expr</c> feature will be approved
and enabled by default. That means that code that uses the
unquoted atom <c>maybe</c> will fail to compile. All uses of
<c>maybe</c> as an atom will need to be quoted. Alternatively, as a
short-term solution, the <c>maybe_expr</c> feature can be
disabled.
</p>
<p>
It is recommend to quote all uses of the atom <c>maybe</c> as soon as
possible. The compiler option <c>warn_keywords</c> can be used to emit
warnings about all occurrences of <c>maybe</c> without quotes.
</p>
</section>
<section>
<marker id="new_re_engine"/>
<title>The re module will use a different regular expression engine</title>
<p>The functionality of module <seeerl
marker="stdlib:re"><c>re</c></seeerl> 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.</p>
<p>The source code for PCRE used by the <c>re</c> 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.</p>
<p>Most likely, the new regular expression library will be <url
href="https://github.com/google/re2">RE2</url>. 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
<url
href="https://github.com/google/re2/wiki/WhyRE2">WhyRE2</url>.</p>
<p>Some of implications of this change are:</p>
<list>
<item><p>We expect that the functions in the <c>re</c> module
will continue to be supported, although some of the options are likely
to be dis-continued.</p></item>
<item><p>It is likely that only pattern matching of UTF8-encoded binaries will be
supported (not Latin1-encoded binaries).</p></item>
<item><p>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 <url
href="https://github.com/google/re2/wiki/Syntax">Syntax</url>
for a description of what RE2 supports.</p></item>
<item><p>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.</p></item>
</list>
</section>
<section>
<marker id="float_matching"/>
<title>0.0 and -0.0 will no longer be exactly equal</title>
<p>Currently, the floating point numbers <c>0.0</c> and <c>-0.0</c>
have distinct internal representations. That can be seen if they are
converted to binaries:</p>
<pre>
1> <input><<0.0/float>>.</input>
<<0,0,0,0,0,0,0,0>>
2> <input><<-0.0/float>>.</input>
<<128,0,0,0,0,0,0,0>></pre>
<p>However, when they are matched against each other or compared
using the <c>=:=</c> operator, they are considered to be
equal. Thus, <c>0.0 =:= -0.0</c> currently returns
<c>true</c>.</p>
<p>In Erlang/OTP 27, <c>0.0 =:= -0.0</c> will return <c>false</c>, and matching
<c>0.0</c> against <c>-0.0</c> will fail. When used as map keys, <c>0.0</c> and
<c>-0.0</c> will be considered to be distinct.</p>
<p>The <c>==</c> operator will continue to return <c>true</c>
for <c>0.0 == -0.0</c>.</p>
<p>To help to find code that might need to be revised, in OTP 27
there will be a new compiler warning when matching against
<c>0.0</c> or comparing to that value using the <c>=:=</c>
operator. The warning can be suppressed by matching against
<c>+0.0</c> instead of <c>0.0</c>.</p>
<p>We plan to introduce the same warning in OTP 26.1, but by default it
will be disabled.</p>
</section>
<section>
<marker id="singleton_typevars"/>
<title>Singleton type variables will become a compile-time error</title>
<p>Before Erlang/OTP 26, the compiler would silenty accept the
following spec:</p>
<pre>
-spec f(Opts) -> term() when
Opts :: {ok, Unknown} | {error, Unknown}.
f(_) -> error.</pre>
<p>In OTP 26, the compiler emits a warning pointing out that the type variable
<c>Unknown</c> is unbound:</p>
<pre>
t.erl:6:18: Warning: type variable 'Unknown' is only used once (is unbound)
% 6| Opts :: {ok, Unknown} | {error, Unknown}.
% | ^</pre>
<p>In OTP 27, that warning will become an error.</p>
</section>
</section>
<section>
<title>OTP 28</title>
<section>
<marker id="fun_creator_pid"/>
<title>Fun creator pid will be removed</title>
<p>
As of OTP 28, the function <seemfa
marker="erts:erlang#fun_info/1"><c>erlang:fun_info/1</c></seemfa>
will not include the <c>{pid,_}</c> element and the function
<seemfa marker="erts:erlang#fun_info/2"><c>erlang:fun_info/2</c></seemfa>
will no longer accept <c>pid</c> as the second argument.</p>
</section>
</section>
<section>
<title>OTP 29</title>
<section>
<title>It will no longer be possible to disable feature maybe_expr</title>
<p>
As of OTP 29, the <c>maybe_expr</c> feature will become
permanent and no longer possible to disable. All uses of
<c>maybe</c> as an atom will need to be quoted.
</p>
<p>
It is recommend to quote all uses of the atom <c>maybe</c> as soon as
possible. The compiler option <c>warn_keywords</c> can be used to emit
warnings about all occurrences of <c>maybe</c> without quotes.
</p>
</section>
</section>
</chapter>
|
