(j3.2006) finalizer issues

[Robert Corbett]

An engineer at Oracle asked me some questions about finalizers.  As I tried to 
find answers to his questions, I became a bit confused.  I have been reading the 
Fortran 2008 standard as modified by Corrigendum 1 and Corrigendum 2.


(1)  The second sentence of paragraph 2 of Clause 4.5.6.2 [76:6-7] states

      A final subroutine shall not reference or
      define an object that has already been
      finalized.

The paragraph preceding Note 4.49 of Clause 4.5.6.3 [76:25-26] states

      When an intrinsic assignment statement is
      executed, if the variable is not an
      unallocated allocatable variable, it is
      finalized after evaluation of the <expr>
      and before the definition of the variable.

The text is as modified by Corrigendum 1.  Taken together, those statements say 
that if a finalizable variable, other than an unallocated allocatable variable, 
is assigned a value by an intrinsic assignment statement, the variable shall not 
subsequently be referenced or defined by a final subroutine.  That restriction 
seems too strong.  It is not obvious what the restriction should be.  One 
possibility is that the restriction applies only to invocations of final 
subroutines arising from the finalization of a specific entity.  That might be 
implied by the phrase "When an entity is finalized" in the second sentence of 
paragraph 1 of Clause 4.5.6.2 [75:21].  After the finalization of that specific 
entity is completed, it and other objects finalized in the process of finalizing 
it could again be referenced or defined by a final subroutine.


(2)  The fifth paragraph (formerly the fourth paragraph) of Clause 4.5.6.3 
[[76:15-16] states

      If an executable construct references a
      function, the result is finalized after
      execution of the innermost executable
      construct containing the reference.

Suppose T is a finalizable type with one integer component.  Interpretation 
F08/0011 ruled that finalization is not done for structure constructors.  
Therefore, the statement

       WRITE (10) (T(1), I = 1, 1000000)

does not invoke any finalizers.  On the other hand, the statement

       WRITE (10) ((MERGE(T(1), T(1), .TRUE.), I = 1, 1000000)

requires a million values to be finalized after execution of the WRITE 
statement.  I recall the question whether the results of function references in 
array and structure constructors that are constant expressions are finalized 
being considered during discussion of interpretation F08/0011.  I thought we 
decided that the results are not finalized, but I cannot find language to that 
effect.  I am uncertain if execution of

       WRITE (10) [ ((MERGE(T1), T(1), .TRUE.), I = 1, 1000000) ]

causes any finalization.


(3)  Paragraph 3 of Clause 4.5.6.2 [76:8] states

      If an object is not finalized, it retains
      its definition status and does not become
      undefined.

That statement seems mostly harmless and, perhaps, pointless.  It might be 
taken, however, to imply that if an object is finalized, it becomes undefined.  
I found no evidence for that in the standard, but I might have missed something.


(4)  Suppose X and Y are nonpointer, nonallocatable variables of the same 
finalizable type.  Suppose the final subroutine for X might reference X and 
might change the value of Y.  Then execution of the intrinsic assignment X = Y 
is equivalent to saving a copy of the value of Y, finalizing X, and then copying 
the saved value to X.

Suppose the function F returns a value of the same type as X and Y.  Then 
execution of the intrinsic assignment X = F(Y) is equivalent to saving a copy of 
the value of F(Y), finalizing X, copying the saved value to X, and then 
finalizing the saved value.

I read a Fortran textbook that advises users to provide a final subroutine for 
all derived types that include pointer components that deallocate those 
components.  Users who take that advice are likely to be surprised when after an 
intrinsic assignment of a value returned by a function, they find the pointers 
in the variable that was assigned to be dangling pointers.  I am not saying that 
the advice the textbook gives is bad, but that it is woefully incomplete.

Robert Corbett