AI22-0126-1
!standard 7.6.1(11/6) 25-04-24 AI22-0126-1/03
!standard 7.6.1(13.1/6)
!class binding interpretation 25-01-13
!status Amendment 1-2022 25-03-21
!status WG9 Approved 25-07-18
!status ARG Approved 13-0-0 25-03-19
!status work item 25-01-13
!status received 25-01-13
!assigned author Randy Brukardt
!submitter Randall Brukardt
!priority Low
!difficulty Medium
!qualifier Clarification
!subject Finalization order of temporary objects
The order in which the finalization of temporary objects is performed is unspecified other than that it is completed before finishing the finalization of the associated master.
All objects belonging to a master associated with an expression or <> are finalized following the usual rules, in addition, any tasks created in that master are awaited.
7.6.1(11/6) specifies the finalization order of all objects that are declared by a declaration (except components, as noted by AI22-0122-1). It does not say anything about the order of other objects, in particular about the anonymous objects created for function results and aggregates (usually known informally as “temporary objects”).
This rule is the only one to describe the general order of finalization within a master. 7.6.1(4) mentions that objects are finalized as part of finalizing a master, but gives no further information. Many other rules in 7.6.1 give details of what it means to finalize particular kinds of objects, which master owns particular temporary objects, and other details of finalization.
What order requirements, if any, apply to temporary objects? (None.)
7.6.1(13.1/6) talks about the finalization of anonymous objects associated with a master construct that is an expression or <>. What about other things associated with the master (tasks and named objects)? (They’re covered too.)
(See summary.)
Modify 7.6.1(11/6): (as modified by AI22-0122-1)
The finalization of a master performs finalization of objects created by declarations (other than components) in the master in the reverse order of their creation. {The order in which finalization of other objects in the master are finalized is unspecified with respect to any other objects of the same master.} 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.
AARM Discussion: "other objects in the master" include the anonymous objects created for function returns and for the evaluation of aggregates. These might be associated with a declaration (in terms of providing values for some portion of the declaration) but not actually created by it.
Modify 7.6.1(13.1/6):
In the case of an expression or <> that is a master construct, finalization of {the associated master}[any (anonymous) objects] occurs after completing evaluation of the expression or <> and all use of {any}[the] objects{ associated with the expression or <>}, prior to starting the execution of any subsequent construct or iteration.
[Author’s note: “the associated master” should really be “the master created by the execution of the master construct”, but that seemed too pedantic and wordy. The two different uses of “associated” in this paragraph are uncomfortable, but I couldn’t find anything better.]
During ARG meeting #63G, the first question was raised. It was agreed that we should be explicit that finalization of temporary objects has no specified order (as the current wording looks more like an oversight than an intended result).
During the meeting, it was suggested to add some wording to 7.6.1(13.1/6) to say the order is unspecified. But that rule only applies to master constructs that are an expression or <>, not all masters as was originally requested.
Moreover, a master associated with an expression can have declared objects from a declare expression (or quantified expression) as well as anonymous temporary objects. Thus, the original proposal was wrong.
The author researched the various AIs that led to the creation of the rule of 7.6.1(13.1/6). None of these considered anything other than temporary objects. It appears to the author that the primary purpose was to specify the point at which the master associated with certain expressions or <>s is finalized, rather than to say anything about objects.
A restrictive reading of 7.6.1(13.1/6) would not even include declared objects in the finalization, which clearly would not be the intent. Moreover, the wording only talks about finalizing objects, but the master could also have tasks that need to be awaited. We have rules to prevent that in declare expressions (in part because the waiting will happen later than it appears from the declare expression syntax), but nothing to prevent it from function results. This could happen in something like:
if F(G.A, [1, 2]) then
We assume that function G returns a limited record type with a scalar component A, and a task component T. Here, the master construct is the entire condition which is the function call F. When that master is finalized, G.T is awaited first, then the anonymous objects created by the evaluation of the aggregate and the function call G are finalized (the latter has no effect in this example, but it would be easy to add a controlled object to the record).
While a case like this is highly unlikely, we want it to be well-defined when the task is awaited.
We therefore generalize 7.6.1(13.1/6) to talk about the finalization of the master rather than specifically talking about objects.
@drepl
The finalization of a master performs finalization of objects (other than components) 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 @i{exist}, as do any types and subtypes defined and created within the master.
@dby
The finalization of a master performs finalization of objects (other than components) created by declarations in the master in the reverse order of their creation. The order in which finalization of other objects in the master are finalized is unspecified with respect to any other objects of the same master. After the finalization of a master is complete, the objects finalized as part of its finalization cease to @i{exist}, as do any types and subtypes defined and created within the master.
@drepl
In the case of an @fa{expression} or <> that is a master construct, finalization of any (anonymous) objects occurs after completing evaluation of the @fa{expression} or <> and all use of any objects, prior to starting the execution of any subsequent construct or iteration.
@dby
In the case of an @fa{expression} or <> that is a master construct, finalization of the associated master occurs after completing evaluation of the @fa{expression} or <> and all use of any objects associated with the @fa{expression} or <>, prior to starting the execution of any subsequent construct or iteration.
Since the order of finalization of temporaries is unspecified, that is untestable beyond ensuring that any temporaries are finalized in the correct master, and we already have ACATS C-Tests for that.
Finalization of objects in a declare expression should also be tested as part of testing of declare expressions. Task waiting associated with a master construct that is an expression or <> could be tested with an ACATS C-Test, but this case is very unlikely and can be considered pathological.
This AI was split from AI22-0122-1 after it was noted that 7.6.1(13.1/6) is dubious in several cases. Additionally, the question about the general rule for the order of temporary finalization was not answered in that AI.
From: Randy Brukardt
Sent: Friday, March 21, 2025
I noticed an issue with the last sentence of the !issue. That was:
What about other things associated with the master (named objects and tasks)? (They’re covered too.)
I was wondering how one could have a named task in an expression. But this is supposed to be read as (parens for grouping here)
(named objects) and (tasks)
Not
(named (objects and tasks))
The usual fix for such things is to reverse the order of the parts, giving:
(tasks and named objects)
Consider this part of my Editorial Review on this AI.