(j3.2006) Finalization ordering question

[Kurt W Hirchert]

Since Malcolm has revived this topic and my name was mentioned at least 
a couple of times in the earlier discussion, I'll throw in my $.02 worth:

1. The text as written carries a clear implication that the extended 
components are to be finalized before the parent component (and thus the 
components of the parent type).

2. There appears to be some confusion about the effect of rank on 
selecting a final subroutine.  My reading of the text is that a scalar 
component uses a scalar final subroutine, regardless of the rank of the 
parent object, because the components for each element are finalized 
separately. 

   Bill thinks the rule is clear for components covered by step (2) but 
not for the parent component (covered by step (3)).  Although it could 
be made clearer, the rule stated in step (2) "If the entity being 
finalized is an array, each finalizable component of each element of 
that entity is finalized separately." does not explicitly exclude the 
parent component, so in the absence of an explicit contrary statement in 
step (3), I would assume that it applies there as well.

3. I point out that the stated order serves only to define the semantics 
of the program.  An optimizing compiler is free to perform those 
operations in a different order, as long as the final result is the 
same.  I expect that it is the rare set of final subroutines where there 
is any order dependencies.  Unfortunately, in final subroutines 
involving pointers, it may be difficult for a compiler to verify that no 
order dependencies exist.

4. Finally, I offer the opinion that the forced ordering that all 
extended components be finalized before the parent component may very 
well be unintended.  As noted earlier in this discussion, my early 
proposals on this subject had a very strong specification of the order 
for performing finalization.  This ordering was included, but secondary 
to the ordering on elements.  All that ordering proved unpopular with 
the committee, so most of it was removed.  Unfortunately, the way this 
was expressed textually had the effect of promoting this formerly 
secondary ordering into a part of the primary ordering.  Instead of just 
allowing a wider range of orderings, this actually imposes an ordering 
inconsistent with the original proposals.  Since there was no discussion 
of this change in ordering, only of removing ordering restrictions, I 
suspect the change was unintended.

   There remains the question of what the committee wants to do about it 
now.  I see three possibilities:
   a. Leave the ordering as it stands.
   b. Completely remove that part of the ordering.  This could be done 
by removing "(3)" and making what is now step (3) a part of step (2) [in 
effect, a statement that the parent component is one of the components 
covered by step (2)].
   c. The ordering between extended components and parent components 
could be interpreted (and textually clarified) to apply on a per element 
basis.  [I.e., the extended components of an element are to be finalized 
before the parent component of that element, but not necessarily before 
the parent components of other elements.]

My first choice would be (b), but I would find (c) acceptable.  I don't 
like (a), because it makes finalization code more complex.  [(b) and (c) 
allow internal finalization to effectively be elemental, while (a) 
effectively requires internal finalization to be an overload of routines 
for each possible rank of the parent object.]

If Malcolm can remember some reason why the existing ordering might be 
considered beneficial, I will defer to him, but otherwise, I suggest the 
committee consider some maintenance on this point.

-Kurt