F2003 Finalization -- progress and problems

[Tobias Burnus]

Hi Daniel,

let's start with the simpler stuff.

Daniel Kraft wrote:
> d) when a procedure is called that is not in a module (does not have an
> interface?) its formal-argument list in the tree is NULL (as this
> information is not known, I suppose).  How should we in this case
> determine which arguments are INTENT(OUT) and need finalization before
> the call?
When the interface is implicit, one can regard the arguments as 
INTENT(INOUT) [though there is a fine destinction between INTENT(INOUT) 
and no INTENT with regards to definability]; in any case there is no 
need to finalize the argument. Note a procedure has always an interface 
in Fortran  - the distrinction is only between explicit and implicit.

> WRITE (*,*) x + foobar (x)
>
> Is this allowed?
I forgot whether modifying the items in an I/O list is invalid or the 
result is only implementation-dependent,  but FINALizing "x" here should 
be OK.

> What's about calling an ELEMENTAL-procedure with a INTENT(OUT) argument
> on an array?  Should the array be finalized as a whole or each element
> seperatelly before the call?
I think if there is an array finalizing subroutine, I'd simply call it 
otherwise, one could either first finalize all elements and call then 
the elemental procedure, or one could finalize an element and then call 
the elemental procedure with this element. The result should be the same 
as "the values of the elements, if any, of the result are the same as 
would have beenn obtained if the scalar function had been applied 
separately, in any order, to the corresponding elements of each array 
actual element." Note especially the "in any order".

+    ! XXX: Scalars can be allocatable, too, can't they?

In Fortran 95: No, in Fortran 2003: Yes. In gfortran: No. Most of the 
time it does not make sense to allocate scalars, exceptions are 
characters with "len=:" where it is useful. Analogously for derived 
types with  LEN type  parameters.

+    TYPE(yes_t), ALLOCATABLE :: alloc_vector(:)
+    ! alloc_vector is deallocated automatically here
+    ! XXX: Or not?

It should be. The local variable "alloc_vector" goes out of scope. (Contrary to pointers; for pointers there could exist another pointer, which still points to the same target.)


Tobias