Like any language, Chapel has changed over time. This page is designed to
capture significant language changes that have the possibility of breaking
existing user codes or code samples from old presentations or papers that
predated the changes.

Note that the compiler flag --warn-unstable is available and can be
useful when migrating programs to the current version of the language.
The purpose of this flag is to identify portions of a program that use a
language feature that has changed meaning.

Before 1.18, if C is a class type, a variable of type C needed
to be deleted in order to prevent a memory leak. For example:

classC{varx:int;}procmain(){varinstance:C=newC(1);deleteinstance;}

Version 1.18 introduced four memory management strategies that form part
of a class type and are used with new expressions:

ownedC

owned classes will be deleted automatically when the owned
variable goes out of scope, but only one owned variable can refer to
the instance at a time.
Such instances can be created with newownedC().

sharedC

shared classes will be deleted when all of the shared variables
referring to the instance go out of scope.
Such instances can be created with newsharedC().

borrowedC

refers to a class instance that has a lifetime managed by
another variable.
Values of type borrowedC can be created with newborrowedC(), by coercion from the other class C types, or by explicitly
calling the .borrow() method on one of the other class C
types.
newborrowedC() creates a temporary instance that will automatically
be deleted at the end of the current block.

unmanagedC

the instance must have delete called on it explicitly to
reclaim its memory.
Such instances can be created with newunmanagedC().

Further note that the default is borrowed, that is:

C

is now the same as borrowedC

newC()

is now the same as newborrowedC()

Now, back to the example above. There are several ways to translate this
program.

First, the most semantically similar option is to replace uses of C
with unmanagedC:

As described in the language changes for 1.12 in
lexical scoping, using arrays beyond their scope
is a user error. While such a program was in error starting with Chapel
1.12, such a pattern worked until Chapel 1.15.

For example, this program will probably crash in Chapel 1.15:

procbadBegin(){varA:[1..10000]int;begin{A+=1;}// Error: A destroyed here at function end, but the begin could still// be using it!}

Similarly, using a slice after an array has been destroyed is an error:

procbadBeginSlice(){varA:[1..10000]int;// slice1 sets up a slice using the => operator// note that the => operator is deprecated (see below)varslice1=>A[1..1000];// slice2 sets up a slice by creating a reference to itrefslice2=A[1..1000];// either way, using the slice in a begin that can continue// after the function declaring the array exits is an errorbegin{slice1+=1;slice2+=1;}// Error: A destroyed here at function end, but the begin tries to// use it through the slices!}

The array alias operator, =>, has been deprecated in Chapel 1.15.
Previously, the supported way to declare one array that aliases another
(or a slice of another) was to use =>. Now, the supported way to do
that is to use a ref or const ref variable:

For example, before Chapel 1.15 you might have written:

// pre-1.15varA:[1..10]int;// set up a const alias of Aconstalias=>A;// set up a mutable slice of Avarslice=>A[2..5];// set up a re-indexing slice of Avarreindex:[0..9]=>A;

In Chapel 1.15, use ref or const ref to create the same pattern:

varA:[1..10]int;// set up a const alias of Aconstrefalias=A;// set up a mutable slice of Arefslice=A[2..5];// set up a re-indexing slice of Arefreindex=A.reindex({0..9});

Before 1.15, the default intent for arrays was ref. The rationale for
this feature was that it was a convenience for programmers who are used
to modifying array formal arguments in their functions. Unfortunately, it
interacted poorly with return intent overloading.
Additionally, the implementation had several bugs in this area.

The following example shows how it might be surprising that return intent
overloading behaves very differently for arrays than for other types. As
the example shows, this issue affects program behavior and not just
const-checking error messages from the compiler.

// First, let's try some of these things with an// associative array of ints:{varD:domain(int);varA:[D]int;// This adds index 1 to the domain, implicitlyA[1]=10;writeln(D.member(1));// outputs `true`// This will halt, because index 2 is not in the domain//var tmp = A[2];// This will also halt, for the same reason//writeln(A[3]);}// Now, let's try the same things with an array of arrays:{varD:domain(int);varAA:[D][1..4]int;varvalue:[1..4]int=[10,20,30,40];// This adds index 4 to the domain, implicitlyAA[4]=value;writeln(D.member(4));// outputs `true`// This will halt, because index 5 is not in the domain//var tmp = AA[5];// It seems that this *should* halt, but it does not (pre 1.15)// Instead, it adds index 6 to the domainwriteln(AA[6]);writeln(D.member(6));// outputs `true` !}

See GitHub issue #5217 for more examples and discussion.

In order to make such programs less surprising, version 1.15 changes the default
intent for arrays to ref if the formal argument is modified in the function
and const ref if not. As a result, the above example behaves similarly for an
associative array of integers and an associative array of dense arrays.

For example, in the following program, the default intent for the formal
argument x is ref:

procsetElementOne(x){// x is modified, so x has ref intentx[1]=1;}varA:[1..10]int;setElementOne(A);

In contrast, in the following program, the default intent for the formal argument y is const ref:

procgetElementOne(y){// y is not modified, so y has const ref intentvartmp=y[1];}constB:[1..10]int;getElementOne(B);

Before 1.15, the default intent for the implicit this argument for
record methods was implemented as ref but specified as const ref. In
1.15, this changed to ref if the formal this argument is modified in
the body of the function and const ref if not.

See GitHub issue #5266 for more details and discussion.

recordR{varfield:int;procsetFieldToOne(){// this is modified, so this-intent is refthis.field=1;}procprintField(){// this is not modified, so this-intent is const refwriteln(this.field);}}

Previous versions of Chapel included an implicit setter param of
type bool for ref return intent functions. In addition, the compiler
created a getter and setter version of each ref return intent function.
The getter version would return an rvalue, and the setter version would
return an lvalue by ref. For example:

In some cases, when migrating code over to the new functionality,
it is useful to put the old ref return intent function into a
helper function with an explicit param setter argument, and then to
call that function from the getter or setter.

Prior to version 1.12 of Chapel, variables could be kept alive past
their lexical scopes. For example:

{varA:[1..n]real;varcount$:syncint;varx:real;beginwith(refx){...A...;...count$...;...x...;}// ^^^ this task and its references to A, count$, and x could outlive// the scope in which those variables are declared.}// So, previously, Chapel kept these variables alive past their// logical scope.

Disadvantages of this approach included:

It moves logical stack variables (like x and count$ above) to
the heap.

Code that refers to lexically scoped variables within tasks in this manner
should use sync variables or blocks in order to guarantee the
tasks's completion before the enclosing block exits. Note that the
more commonly used cobegin, coforall, and forall statements
already guarantee that the tasks they create will complete before the
enclosing block exits.

In previous versions of Chapel, the bodies of forall-loops have referred to
all lexically visible variables by reference. In this release of Chapel, such
variables are treated more consistently with the task intent semantics and
syntax introduced in versions 1.8 and 1.10 respectively (described below).

Specifically, prior to this release, a loop like the following would
represent a data race:

varsum=0.0;forallainAdosum+=a;

since multiple iterations of the loop could execute simultaneously, read
the identical value from the shared variable sum, update it, and write the
result back in a way that could overwrite other simultaneous updates.

Under the new forall intent semantics, such variables are treated as though
they are passed by "blank intent" to the loop body (so const for variables of
scalar type like sum, preventing races in such cases). This mirrors the task
intent semantics for variables referenced within begin, cobegin, and coforall
constructs. As in those cases, a user can specify semantics other than the
default via a with-clause. For example, to restore the previous race-y
semantics, one could write:

varsum=0.0;forallainAwith(refsum)dosum+=a;

(Of course, the safe way to write such an idiom would be to use a
reduction, or a synchronization type like sync or atomic).

Chapel has traditionally supported a typeselect statement that was
like a select statement for types. However, this seemed inconsistent with the
fact that other constructs like if...then operate on types directly. For that
reason, this release removed support for typeselectx. Instead, use the
equivalent selectx.type.

Task intent clauses were added to Chapel in version 1.8 to
support passing variables by reference into tasks. Since then, the need to pass
variables by other intents and into other parallel constructs has arisen. But,
the previous syntax was problematic to extend to other intents, while also
generating syntactic ambiguities for other additions we wished to make to the
language.

For these reasons, a new task intent syntax was designed to cleanly support
intents other than ref (particularly in looping contexts), to address the
pending ambiguity, and to better reflect the similarity of task intents to
formal argument lists. Where previously, task constructs could be followed by a
ref clause, they can now be followed by a with clause that takes a list of
intents and variables, specifying how to pass them into the task.

A var function return intent has traditionally been used to indicate that
a call to the function (referred to as a var function) could appear in either
an r-value or l-value context. The var keyword was chosen since the function
could be used in the same contexts as a variable could.

Since that time, the ref keyword has been introduced into Chapel to
support passing variables by reference to functions. Since returning an
expression by reference supports similar capabilities as var functions require,
while also being less unusual/more orthogonal, this release replaces var
function return intents with ref intents.

Thus, where one would previously write:

procgetFoo()var{...}

now you would write:

procgetFoo()ref{...}

The var as a return intent is deprecated and generates a warning for the
current release, after which it will be removed.

Historically, Chapel's operator precedence choices have tended to follow the
lead of C for operators that are common to both languages, figuring that
following an established convention would be better than forging our own path.

With this change, we modified the precedence of bitwise operators to better
reflect what we think it intuitive to users and correct what is viewed in many
circles to be a regrettable mistake in C. At the same time, we changed the
binding of in and .. to support some other Chapel idioms more naturally,
like 1..10==1..10. To see the current operator precedence, refer to the
:download:Quick Reference <https://chapel-lang.org/spec/quickReference.pdf> sheet.

Historically, for a domain D, Chapel has interpreted {D} as being equivalent to
D, inheriting a precedent of sorts set by the ZPL language, and dating from a
time when we used square brackets for both domain literals and array types.

With this change, we began interpreting {D} as a domain literal with a
single index, D (i.e., an associative domain of domains). Associative domains
of domains are not yet implemented in the language, so the new syntax is not
yet useful, but at least the incongruity of ignoring the curly brackets has
been removed.

task functions and intents; ref-clauses Chapel has three constructs for
creating tasks: begin, cobegin, and coforall. Historically, variable references
within tasks followed standard lexical scoping rules. For example, the
following code:

varx=0;beginwriteln(x);x+=1;

could print either the value 0 or 1, depending on whether the writeln()
task was executed before or after the increment of x.

With this change, we view the creation of a task as an invocation of a task function
— a compiler-created function that implements the task. Any references
to variables outside of the task's scope (like x in the example above) are
treated as implicit arguments to the task function, passed by blank intent.

Thus, when x is an integer, as in the above code, the task will always
print the value of 0, even if the increment of x is executed before the
writeln() task, since the value of x will have been passed to the task function
by blank intent (implying a const copy for integer arguments). In contrast, if
x were a sync variable in the example above, the blank intent would cause it to
be passed by reference to the task, permitting the task to see either of the
values 0 or 1.

To return to the previous behavior, a ref-clause can be added to the
tasking construct to indicate that a variable should be passed to the task
function by reference rather than blank intent. For example, the following
code:

varx=0;beginref(x)writeln(x);x+=1;

would revert to the previous behavior, even if x were an integer.

For more information on this feature, please refer to the Task Intents
section of the Task Parallelism and Synchronization chapter of the language
specification.

In this change, we made domain literals use curly brackets in order to
reflect their role as sets of indices, and also to make square brackets
available for supporting array literals. Thus, {1..m,1..n} is an m × n index
set, [1.2,3.4,5.6] is a 3-element array of reals and [1..m,1..n] is a
2-element array of ranges.

Emacs users working on updating existing code can use the following recipe
to update old-style domain literals to the new syntax:

Zippered iteration in Chapel was traditionally supported
simply by iterating over a tuple of values. For example, forall (i,a) in
(1..n,A) would iterate over the range 1..n and the n-element array
A in a zippered manner.

In this change, we introduced the zip keyword to make these zippered
iterations more explicit and to permit iteration over a tuple's values
directly. Thus, the zippered iteration above would now be written:

Overtime, the mechanism used to ignore a tuple component when destructuring a tuple
has changed.
Originally, an underscore was used to drop a value on the floor. For example,
given a 3-tuple t, the first and last components could be stored in x and z,
dropping the second component on the floor using: var(x,_,z)=t;.
In version 1.1 (Apr 2010), we changed this to use a blank space instead of an
underscore, for simplicity and to permit underscore to be used as an identifier
name. Thus, the example above would have been written as var(x,,z)=t;
during this time period.

However, in 2012, we changed back to using the underscore again in order to
support the specification of 1-tuples using a dangling comma, similar to
Python. Thus, dropping a tuple component is expressed as var(x,_,z)=t;
again while (1.2,) is a 1-tuple of reals.

Prior to this change, the keyword def was used to
define both procedures and iterators; the compiler inspected the body of the
function for yield statements to determine whether it was a procedure or an
iterator.

In this change, we introduced the proc and iter keywords to distinguish
between these two cases for the sake of clarity, to avoid mistakes, to support
semantics that clearly distinguish between these cases, and to better support
specifying interfaces.