AI22-0122-1
!standard 7.6.1(11/3) 25-04-18 AI22-0122-1/03
!class binding interpretation 24-11-26
!status Amendment 1-2022 25-01-10
!status WG9 Approved 25-07-18
!status ARG Approved 15-0-0 25-01-09
!status work item 24-11-26
!status received 22-02-22
!submitter Stephen Baird
!priority Low
!difficulty Easy
!qualifier Clarification
!subject Order of finalization of components
The order of finalization of components is loosely determined by 7.6.1(9/3); the stricter order of 7.6.1(11/3) only applies to objects that are not components.
7.6.1(9/3) specifies that components are finalized in an arbitrary order (with exceptions). However, 7.6.1(11/3) specifies a strict order for "objects created by declarations". Components are objects, and they certainly are created by declarations, so it seems that 7.6.1(11/3) overrides 7.6.1(9/3) and makes it moot. It is unlikely that was the intent.
7.6.1(11/3) should apply only to objects that are not components.
Modify 7.6.1(11/3):
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 exist, as do any types and subtypes defined and created within the master.
{AARM Reason: This rule covers all "top-level" objects (stand-alone objects along with any other object that is not a component of an enclosing object) that are created in a master. Components of top-level composite objects are covered by previous rules, which have a weaker required order.}
It's pretty clear that the intent was that components would only have a very weak order requirement, and that the strong ordering of 7.6.1(11/3) is intended to apply only to top-level declarations. Thus, we reword 7.6.1(11/3) to make that clear.
Since this change is clarifying an existing rule, and the clarification can only allow more implementation freedom, no implementation should need to be changed for the change made by this AI.
Some random points based on the private discussion that led to this AI:
The components that are finalized first (that is, that require "early finalization" [which is not a term but convenient to use here]) are a subset of the components that are initialized last (that require "late initialization", which is a term). That seems weird, but it is OK because late initialization that is required for reasons associated with the default expression need have no impact when finalizing components. The rule was written to give maximum flexibility to implementations, only requiring an order when absolutely necessary.
One wording suggestion was to add "stand-alone" to 7.6.1(11/3), rather than the wordier phrasing that is used above. However, "stand-alone" objects are only those created by object_declarations or are in formal parameters of a generic instance. Other "top-level" objects can exist, in particular (anonymous) objects (“temporary” objects) created by the evaluation of expressions inside of a generic_instance [which is a kind of declaration]. 7.6.1(11/3) reads as if it is complete, that is, it specifies all objects that are to be finalized for a master. We certainly want to finalize all objects that might be top-level, thus the use of "stand-alone" would be wrong
However, temporary objects are not usually created by a declaration (they’re created by function calls, evaluation of aggregates, and similar constructs), and thus are not given an order by 7.6.1(11/3). It is fine to leave the order of their finalization unspecified, but it seems useful to make it clear that having an unspecified order is intentional. That will be handled in a separate AI.
Note that we want 7.6.1(9/3) to apply to all finalization of composite objects, not just top-level composite objects. If a composite object C is a component of another composite object, we still need the components that require "early finalization" to be finalized before any other components of C. Thus, no wording change is needed for 7.6.1(9/3).
The question arose whether parent components are considered to be declared before extension components for a type extension. Paragraphs 3.4(10-14) seem to define the order, and 3.4(14) says specifically that the declarations are made "in the order indicated above". So the rules in 3.3.1 and 7.6.1 that assume an order for component declarations are in fact well-defined for type extensions.
@drepl
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 @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. 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.
It's not possible to test "arbitrary order", so no new tests are needed. Existing tests should check for "early finalization" components and finalization order of top-level objects, but have no other order requirements.
This topic was originally raised by Steve Baird in private e-mails in February 2022.
The change to 7.6.1(13.1/6) added during meeting #63G was removed as part of Editorial Review. If the parameter is read to cover all objects being finalized for a master construct that is an expression, the addition would conflict with both the new and old versions of 7.6.1(11/3). That’s because an expression can contain object_declarations are part of a declare_expression. Those have a defined order, and we would not want working that implies that they do not. It seems that 7.6.1(13.1/6) itself deserves a clarification, and the original question about 7.6.1(11/3) and temporary objects remains unanswered. We’ll handle both of those in a separate AI (AI22-0126-1); the topic of this AI is adequately addressed by the change to 7.6.1(11/3) alone.