7.6.1 Completion and Finalization
[This subclause defines completion
of the execution of constructs and entities. A master
is the execution
of a construct that includes finalization of local objects after it is
complete (and after waiting for any local tasks — see 9.3
but before leaving. Other constructs and entities are left immediately
The execution of a construct
or entity is complete
when the end of that execution has been
reached, or when a transfer of control (see 5.1
causes it to be abandoned.
due to reaching the end of execution, or due to the transfer of control
of an exit_statement
return statement, goto_statement
or of the selection of a terminate_alternative
is normal completion
. Completion is abnormal
[— when control is transferred out of a construct due to abort
or the raising of an exception].
Don't confuse the run-time
concept of completion with the compile-time concept of completion defined
After execution of a construct
or entity is complete, it is left
, meaning that execution continues
with the next action, as defined for the execution that is taking place.
Leaving an execution happens immediately after its
completion, except in the case of the execution
of a master construct a master
: the execution of
a body other than a package_body
the execution of
or the evaluation of
is not part of an enclosing expression
other than a simple_return_statement
The term master by itself refers to the
execution of a master construct.
A master is finalized after it
is complete, and before it is left.
Glossary entry: A
master is the execution of a master construct. Each object and task is
associated with a master. When a master is left, associated tasks are
awaited and associated objects are finalized.
A master construct is one of certain executable constructs listed in
7.6.1. Execution of a master construct is
a master, with which objects and tasks are associated for the purposes
of waiting and finalization.
For the finalization
a master, dependent tasks are first awaited, as explained in 9.3
Then each object whose accessibility level is the same as that of the
master is finalized if the object was successfully initialized and still
exists. [These actions are performed whether the master is left by reaching
the last statement or via a transfer of control.] When a transfer of
control causes completion of an execution, each included master is finalized
in order, from innermost outward.
As explained in 3.10.2
the set of objects with the same accessibility level as that of the master
includes objects declared immediately within the master, objects declared
in nested packages, objects created by allocator
(if the ultimate ancestor access type is declared in one of those places)
and subcomponents of all of these things. If an object was already finalized
by Unchecked_Deallocation, then it is not finalized again when the master
Note that any object whose accessibility level
is deeper than that of the master would no longer exist; those objects
would have been finalized by some inner master. Thus, after leaving a
master, the only objects yet to be finalized are those whose accessibility
level is less deep than that of the master.
To be honest: Subcomponents of objects
due to be finalized are not finalized by the finalization of the master;
they are finalized by the finalization of the containing object.
Reason: We need to finalize subcomponents
of objects even if the containing object is not going to get finalized
because it was not fully initialized. But if the containing object is
finalized, we don't want to require repeated finalization of the subcomponents,
as might normally be implied by the recursion in finalization of a master
and the recursion in finalization of an object.
To be honest: Formally, completion and
leaving refer to executions of constructs or entities. However, the standard
sometimes (informally) refers to the constructs or entities whose executions
are being completed. Thus, for example, “the subprogram call or
task is complete” really means “the execution of the
subprogram call or task is complete”.
of an object:
If the full type of the object is an elementary type, finalization has
We say “full type” in this and the following bullets as privacy
is ignored for the purpose of determining the finalization actions of
an object; that is as expected for Dynamic Semantics rules.
If the full type of the object is a tagged type, and the tag of the object
identifies a controlled type, the Finalize procedure of that controlled
type is called;
If the full type of the object is a protected type, or if the full type
of the object is a tagged type and the tag of the object identifies a
protected type, the actions defined in 9.4
If the full type of the object is a composite type, then after performing
the above actions, if any, every component of the object is finalized
in an arbitrary order, except as follows:
object has a component with an access discriminant constrained by a per-object
expression, this component is finalized before any components that do
not have such discriminants; for an object with several components with
such a discriminant, they are finalized in the reverse of the order of
Reason: This allows the finalization
of a component with an access discriminant to refer to other components
of the enclosing object prior to their being finalized.
To be honest:
The components discussed here are all of the components that the object
actually has, not just those components that are statically identified
by the type of the object. These can be different if the object has a
If the object has coextensions (see 3.10.2
each coextension is finalized after the object whose access discriminant
In the case of an aggregate
or function call that is used (in its entirety) to directly initialize
a part of an object, the coextensions of the result of evaluating the
or function call are transfered to become coextensions of the object
being initialized and are not finalized until the object being initialized
is ultimately finalized, even if an anonymous object is created as part
of the operation.
Immediately before an instance
of Unchecked_Deallocation reclaims the storage of an object, the object
is finalized. [If an instance of Unchecked_Deallocation is never applied
to an object created by an allocator
the object will still exist when the corresponding master completes,
and it will be finalized then.]
The finalization of a master performs finalization of objects created
by declarations in the master in the reverse order of their creation.
After the finalization of a master is complete, the objects finalized
as part of its finalization cease to exist
, as do any types and
subtypes defined and created within the master.
Ramification: Note that a deferred constant
declaration does not create the constant; the full constant declaration
creates it. Therefore, the order of finalization depends on where the
full constant declaration occurs, not the deferred constant declaration.
An imported object is not created by its declaration.
It is neither initialized nor finalized.
Implementation Note: An implementation
has to ensure that the storage for an object is not reclaimed when references
to the object are still possible (unless, of course, the user explicitly
requests reclamation via an instance of Unchecked_Deallocation). This
implies, in general, that objects cannot be deallocated one by one as
they are finalized; a subsequent finalization might reference an object
that has been finalized, and that object had better be in its (well-defined)
Each nonderived access type T
has an associated collection
which is the set of objects created by allocator
, or of types derived from T
removes an object from its collection. Finalization of a collection consists
of finalization of each object in the collection, in an arbitrary order.
The collection of an access type is an object implicitly declared at
the following place:
The place of the implicit declaration determines when allocated objects
are finalized. For multiple collections declared at the same place, we
do not define the order of their implicit declarations.
Finalization of allocated objects is done according to the (ultimate
type, not according to the storage pool in which they are allocated.
Pool finalization might reclaim storage (see 13.11
”), but has
nothing (directly) to do with finalization of the pool elements.
Note that finalization is done only for objects that still exist; if
an instance of Unchecked_Deallocation has already gotten rid of a given
pool element, that pool element will not be finalized when the master
Note that we talk about the type of the allocator
here. There may be access values of a (general) access type pointing
at objects created by allocator
for some other type; these are not (necessarily) finalized at this point.
For a named access type, the first freezing point
) of the type.
The freezing point of the ultimate ancestor access type is chosen because
before that point, pool elements cannot be created, and after that point,
access values designating (parts of) the pool elements can be created.
This is also the point after which the pool object cannot have been declared.
We don't want to finalize the pool elements until after anything finalizing
objects that contain access values designating them. Nor do we want to
finalize pool elements after finalizing the pool object itself.
For the type of an access parameter, the call that
contains the allocator
For the type of an access result, within the master
of the call (see 3.10.2
To be honest:
We mean at a place within the master consistent with the execution of
the call within the master. We don't say that normatively, as it is difficult
to explain that when the master of the call need not be the master that
immediately includes the call (such as when an anonymous result is converted
to a named access type).
For any other anonymous access type, the first
freezing point of the innermost enclosing declaration.
The master of an object is the master enclosing its creation whose accessibility
level (see 3.10.2
) is equal to that of the
object, except in the case of an anonymous object representing the result
of an aggregate
or function call. If such an anonymous object is part of the result of
evaluating the actual parameter expression for an explicitly aliased
parameter of a function call, the master of the object is the innermost
master enclosing the evaluation of the aggregate
or function call, excluding the aggregate
or function call itself. Otherwise, the master of such an anonymous object
is the innermost master enclosing the evaluation of the aggregate
or function call, which may be the aggregate
or function call itself.
paragraph was deleted.
This effectively imports all of the special rules for the accessibility
level of renames, allocator
and so on, and applies them to determine where objects created in them
are finalized. For instance, the master of a rename of a subprogram is
that of the renamed subprogram.
we assign an accessibility level
to the result of an aggregate
or function call that is used to directly initialize a part of an object
based on the object being initialized. This is important to ensure that
any access discriminants denote objects that live at least as long as
the object being initialized. However, if the result of the aggregate
or function call is not built directly in the target object, but instead
is built in an anonymous object that is then assigned to the target,
the anonymous object needs to be finalized after the assignment rather
than persisting until the target object is finalized (but not its coextensions).
(Note than an implementation is never required to create such an anonymous
object, and in some cases is required to not
have such a separate
object, but rather to build the result directly in the target.)
The special case for explicitly aliased parameters of functions is needed
for the same reason, as access discriminants of the returned object may
designate one of these parameters. In that case, we want to lengthen
the lifetime of the anonymous objects as long as the possible lifetime
of the result.
We don't do a similar change for other kinds of calls, because the extended
lifetime of the parameters adds no value, but could constitute a storage
leak. For instance, such an anonymous object created by a procedure call
in the elaboration part of a package body would have to live until the
end of the program, even though it could not be used after the procedure
returns (other than via Unchecked_Access).
Note that the lifetime of the master given to anonymous objects in explicitly
aliased parameters of functions is not necessarily as long as the lifetime
of the master of the object being initialized (if the function call is
used to initialize an allocator
for instance). In that case, the accessibility check on explicitly aliased
parameters will necessarily fail if any such anonymous objects exist.
This is necessary to avoid requiring the objects to live as long as the
access type or having the implementation complexity of an implicit coextension.
Bounded (Run-Time) Errors
It is a bounded error for a call on Finalize or Adjust
that occurs as part of object finalization or assignment to propagate
an exception. The possible consequences depend on what action invoked
the Finalize or Adjust operation:
Ramification: It is not a bounded error
for Initialize to propagate an exception. If Initialize propagates an
exception, then no further calls on Initialize are performed, and those
components that have already been initialized (either explicitly or by
default) are finalized in the usual way.
It also is not a bounded error for an explicit call to Finalize or Adjust
to propagate an exception. We do not want implementations to have to
treat explicit calls to these routines specially.
For an Adjust invoked as part of assignment operations other than those
invoked as part of an assignment_statement
other adjustments due to be performed might or might not be performed,
and then Program_Error is raised. During its propagation, finalization
might or might not be applied to objects whose Adjust failed.
an Adjust invoked as part of an assignment_statement
any other adjustments due to be performed are performed, and then Program_Error
In the case of assignments that are part of initialization, there is
no need to complete all adjustments if one propagates an exception, as
the object will immediately be finalized. So long as a subcomponent is
not going to be finalized, it need not be adjusted, even if it is initialized
as part of an enclosing composite assignment operation for which some
adjustments are performed. However, there is no harm in an implementation
making additional Adjust calls (as long as any additional components
that are adjusted are also finalized), so we allow the implementation
flexibility here. On the other hand, for an assignment_statement
it is important that all adjustments be performed, even if one fails,
because all controlled subcomponents are going to be finalized. Other
kinds of assignment are more like initialization than assignment_statement
so we include them as well in the permission.
Even if an Adjust invoked as part of the initialization of a controlled
object propagates an exception, objects whose initialization (including
any Adjust or Initialize calls) successfully completed will be finalized.
The permission above only applies to objects whose Adjust failed. Objects
for which Adjust was never even invoked must not be finalized.
For a Finalize invoked as part
of a call on an instance of Unchecked_Deallocation, any other finalizations
due to be performed are performed, and then Program_Error is raised.
The standard does not specify if storage is recovered in this case. If
storage is not recovered (and the object continues to exist), Finalize
may be called on the object again (when the allocator
master is finalized).
For a Finalize invoked due to reaching the end of
the execution of a master, any other finalizations associated with the
master are performed, and Program_Error is raised immediately after leaving
This rule covers both ordinary objects created by a declaration, and
anonymous objects created as part of evaluating an expression
All contexts that create objects that need finalization are defined to
For a Finalize invoked by the transfer of control
of an exit_statement
return statement, goto_statement
Program_Error is raised no earlier than after the finalization of the
master being finalized when the exception occurred, and no later than
the point where normal execution would have continued. Any other finalizations
due to be performed up to that point are performed before raising Program_Error.
For example, upon leaving
due to a goto_statement
the Program_Error would be raised at the point of the target statement
denoted by the label, or else in some more dynamically nested place,
but not so nested as to allow an exception_handler
that has visibility upon the finalized object to handle it. For example,
procedure Main is
Outer_Block_Statement : declare
X : Some_Controlled_Type;
Inner_Block_Statement : declare
Y : Some_Controlled_Type;
Z : Some_Controlled_Type;
when Program_Error => ... -- Handler number 1.
when Program_Error => ... -- Handler number 2.
when Program_Error => ... -- Handler number 3.
will first cause Finalize(Z Y
to be called. Suppose that Finalize(Z Y
propagates an exception. Program_Error will be raised after leaving Inner_Block_Statement,
but before leaving Main. Thus, handler number 1 cannot handle this Program_Error;
it will be handled either by handler number 2 or handler number 3. If
it is handled by handler number 2, then Finalize(Y Z
will be done before executing the handler. If it is handled by handler
number 3, then Finalize(Y Z
and Finalize(X) will both be done before executing the handler.
For a Finalize invoked by a transfer of control
that is due to raising an exception, any other finalizations due to be
performed for the same master are performed; Program_Error is raised
immediately after leaving the master.
If, in the above example, the goto_statement
were replaced by a raise_statement
then the Program_Error would be handled by handler number 2, and Finalize(Y Z
would be done before executing the handler.
We considered treating this case
in the same way as the others, but that would render certain exception_handler
useless. For example, suppose the only exception_handler
is one for others
in the main subprogram. If some deeply nested
call raises an exception, causing some Finalize operation to be called,
which then raises an exception, then normal execution “would have
continued” at the beginning of the exception_handler
Raising Program_Error at that point would cause that handler's code to
be skipped. One would need two nested exception_handler
to be sure of catching such cases!
On the other hand, the exception_handler
for a given master should not be allowed to handle exceptions raised
during finalization of that master.
For a Finalize invoked by a transfer of control
due to an abort or selection of a terminate alternative, the exception
is ignored; any other finalizations due to be performed are performed.
Ramification: This case includes an asynchronous
transfer of control.
To be honest:
violates the general principle that it is always possible for a bounded
error to raise Program_Error (see 1.1.5
“Classification of Errors
If the execution of an allocator
propagates an exception, any parts of the allocated object that were
successfully initialized may be finalized as part of the finalization
of the innermost master enclosing the allocator
Reason: This allows deallocating the
memory for the allocated object at the innermost master, preventing a
storage leak. Otherwise, the object would have to stay around until the
finalization of the collection that it belongs to, which could be the
entire life of the program if the associated access type is library level.
The implementation may finalize objects created by allocator
for an access type whose storage pool supports subpools (see 13.11.4
as if the objects were created (in an arbitrary order) at the point where
the storage pool was elaborated instead of at the first freezing point
of the access type.
This allows the finalization
of such objects to occur later than they otherwise would, but still as
part of the finalization of the same master. Accessibility rules in 13.11.4
ensure that it is the same master (usually that of the environment task).
This permission is intended to allow the allocated objects to "belong"
to the subpool objects and to allow those objects to be finalized at
the time that the storage pool is finalized (if they are not finalized
earlier). This is expected to ease implementation, as the remaining
objects will only need to be
accessible at run time from the subpool header and not also from the
overall access type collection header. That is, they only need to belong
to a single list, rather than two belong
to the subpool and not also to the collection
The rules of Clause 10 imply that immediately prior to partition termination,
Finalize operations are applied to library-level controlled objects (including
those created by allocator
of library-level access types, except those already finalized). This
occurs after waiting for library-level tasks to terminate.
Discussion: We considered defining a
pragma that would apply to a controlled type that would suppress Finalize
operations for library-level objects of the type upon partition termination.
This would be useful for types whose finalization actions consist of
simply reclaiming global heap storage, when this is already provided
automatically by the environment upon program termination.
21 A constant is only constant between
its initialization and finalization. Both initialization and finalization
are allowed to change the value of a constant.
22 Abort is deferred during certain operations
related to controlled types, as explained in 9.8
Those rules prevent an abort from causing a controlled object to be left
in an ill-defined state.
23 The Finalize procedure is called upon
finalization of a controlled object, even if Finalize was called earlier,
either explicitly or as part of an assignment; hence, if a controlled
type is visibly controlled (implying that its Finalize primitive is directly
callable), or is nonlimited (implying that assignment is allowed), its
Finalize procedure should be designed to have no ill effect if it is
applied a second time to the same object.
Discussion: Or equivalently, a Finalize
procedure should be “idempotent”; applying it twice to the
same object should be equivalent to applying it once.
A user-written Finalize procedure
should be idempotent since it can be called explicitly by a client (at
least if the type is "visibly" controlled). Also, Finalize
is used implicitly as part of the assignment_statement
if the type is nonlimited, and an abort is permitted to disrupt an assignment_statement
between finalizing the left-hand side and assigning the new value to
it (an abort is not permitted to disrupt an assignment operation between
copying in the new value and adjusting it).
Either Initialize or Adjust, but not both, is applied to (almost) every
controlled object when it is created: Initialize is done when no initial
value is assigned to the object, whereas Adjust is done as part of assigning
the initial value. The one exception is the object initialized by an
(both the anonymous object created for an aggregate, or an object initialized
by an aggregate
that is built-in-place); Initialize is not applied to the aggregate
as a whole, nor is the value of the aggregate
or object adjusted.
of the following use the assignment operation, and thus perform value
explicit initialization of a stand-alone object
) or of a pool element (see 4.8
default initialization of a component of a
stand-alone object or pool element (in this case, the value of each component
is assigned, and therefore adjusted, but the value of the object as a
whole is not adjusted);
function return, when the result is not built-in-place (adjustment of
the result happens before finalization of the function);
predefined operators (although the only one
that matters is concatenation; see 4.5.3
generic formal objects of mode in
); these are defined in terms of constant
also use the assignment operation, but adjustment never does anything
interesting in these cases:
By-copy parameter passing uses the assignment
operation (see 6.4.1
), but controlled objects
are always passed by reference, so the assignment operation never does
anything interesting in this case. If we were to allow by-copy parameter
passing for controlled objects, we would need to make sure that the actual
is finalized before doing the copy back for [in
The finalization of the parameter itself needs to happen after the copy
back (if any), similar to the finalization of an anonymous function return
object or aggregate
loops use the assignment operation
), but since the type of the loop parameter
is never controlled, nothing interesting happens there, either.
Objects initialized by function results and aggregate
that are built-in-place. In this case, the assignment operation is never
executed, and no adjustment takes place. While built-in-place is always
allowed, it is required for some types — see 7.5
— and that's important since
limited types have no Adjust to call.
Finalization of the parts of a protected object
are not done as protected actions. It is possible (in pathological cases)
to create tasks during finalization that access these parts in parallel
with the finalization itself. This is an erroneous use of shared variables.
Implementation Note: One implementation
technique for finalization is to chain the controlled objects together
on a per-task list. When leaving a master, the list can be walked up
to a marked place. The links needed to implement the list can be declared
(privately) in types Controlled and Limited_Controlled, so they will
be inherited by all controlled types.
Another implementation technique, which we refer
to as the “PC-map” approach essentially implies inserting
exception handlers at various places, and finalizing objects based on
where the exception was raised.
PC-map approach is for the compiler/linker to create a map of code addresses;
when an exception is raised, or abort occurs, the map can be consulted
to see where the task was executing, and what finalization needs to be
performed. This approach was given in the Ada 83 Rationale as a possible
implementation strategy for exception handling — the map is consulted
to determine which exception handler applies.
If the PC-map approach is used, the implementation
must take care in the case of arrays. The generated code will generally
contain a loop to initialize an array. If an exception is raised part
way through the array, the components that have been initialized must
be finalized, and the others must not be finalized.
It is our intention that both of these implementation
methods should be possible.
Wording Changes from Ada 83
Finalization depends on the concepts of completion and leaving, and on
the concept of a master. Therefore, we have moved the definitions of
these concepts here, from where they used to be in Clause 9
These concepts also needed to be generalized somewhat. Task waiting is
closely related to user-defined finalization; the rules here refer to
the task-waiting rules of Clause 9
Inconsistencies With Ada 95
Ada 2012 Correction:
Changed the definition
of the master of an anonymous object used to directly initialize an object,
so it can be finalized immediately rather than having to hang around
as long as the object. In this case, the Ada 2005 definition was inconsistent
with Ada 95, and Ada 2012 changes it back. It is unlikely that many compilers
implemented the rule as written in Amendment 1, so an inconsistency is
unlikely to arise in practice.
Wording Changes from Ada 95
Fixed the wording to say that anonymous objects aren't
finalized until the object can't be used anymore.
Added wording to clarify what happens when Adjust
or Finalize raises an exception; some cases had been omitted.
Revised the definition of master to include expression
in order to cleanly define what happens for tasks and controlled objects
created as part of a subprogram call. Having done that, all of the special
wording to cover those cases is eliminated (at least until the Ada comments
start rolling in).
We define finalization of the collection
here, so as to be able
to conveniently refer to it in other rules (especially in 4.8
Clarified that a coextension is finalized at the same time as the outer
object. (This was intended for Ada 95, but since the concept did not
have a name, it was overlooked.)
Inconsistencies With Ada 2005
Better defined when objects allocated
from anonymous access types are finalized. This could be inconsistent
if objects are finalized in a different order than in an Ada 2005 implementation
and that order caused different program behavior; however programs that
depend on the order of finalization within a single master are already
fragile and hopefully are rare.
Wording Changes from Ada 2005
Removed a redundant rule, which is now covered by
the additional places where masters are defined.
Clarified the finalization rules so that there is
no doubt that privacy is ignored, and to ensure that objects of class-wide classwide
interface types are finalized based on their specific concrete type.
Allowed premature finalization of parts of failed
This could be an inconsistency, but the previous behavior is still allowed
and there is no requirement that implementations take advantage of the
Added a permission to finalize an object allocated from a subpool later
Added text to specially define the master of anonymous objects which
are passed as explicitly aliased parameters (see 6.1
of functions. The model for these parameters is explained in detail in
Wording Changes from Ada 2012
Correction: Defined the term “master
construct”, so as to put static accessibility rules on a firmer
basis, including ensuring that those rules apply inside of generic bodies.
Ada 2005 and 2012 Editions sponsored in part by Ada-Europe