(j3.2006) functions with allocatable result variables

[Malcolm Cohen]

>Paragraph 4 of clause 6.7.3.2 states
...
>If the result of executing a function reference cannot
>be "an allocatable result,"that text is defective.

No it's not.  Don't get confused between a "function result" (a.k.a. result 
variable) and the result of executing a function.  Horses of different colours.

The exposition is not exactly brilliant, but it's not actually broken.

>Regardless of whether the result of executing a
>function reference can or cannot be an argument of
>the intrinsic function ALLOCATED, my question
>regarding deallocation of function results stands.

Yes, I understand the issue.  When those words were written (F95) they seemed 
reasonable.

>Consider the code fragment
>
>       DO, WHILE(G(F()))

The standard states that this is interpreted as
   DO
       IF (.NOT.g(f()))) EXIT

therefore your chain of reasoning falls to the ground - the result of executing 
f() will be deallocated on completion of the (virtual) logical IF statement.

>According to the text cited above, the results of
>executing F() are deallocated only after execution
>of the DO construct is complete.

According to 8.1.6.6.1, that is not what happens.

Anyway, even if for the sake of argument we pick some different situation where 
there is a big construct that is executed for some time after the result of the 
function is no longer needed, as long as
(a) the result variable does not have the TARGET attribute,
and
(b) the result is not finalisable,
the processor can deallocate it earlier without affecting any program semantics. 
It is thus almost always the case that this can be done.

When we wrote this we were trying to get to the situation where the user program 
had a reasonable guarantee of when the deallocation would occur, but without 
putting overly onerous requirements on the processor.  And without the standard 
being too complicated to understand (we did not want lots of special cases). 
And without using vague handwaving like "deallocated when the processor has 
finished with the result".  I'm sure this could be further improved, but there 
is not any obvious big improvement in clear sight.  Feel free to make 
suggestions though (but unless the current situation is seriously broken they 
will probably have to be feature changes for the next revision).

Cheers,
-- 
................................Malcolm Cohen, Nihon NAG, Tokyo.