Re: Constraints on variables in pure procedures

[Brooks Moses <bmoses at stanford dot edu>]

(I was clearing out old unanswered stuff, and came across this post from 
 a while ago.  The situation hasn't changed, though, so it seems still 
relevant.)

THOMAS Paul Richard 169137 wrote on 2006/03/03:
> If I have understood things correctly, the intention of the constraints
> on variables within pure procedures is to:
>
> (i) Prevent a pure procedure to change the value of global variables,
> dummy arguments with INTENT(IN), or no declared intent, and objects that
> are associated with any part of a global variable; and to
> (ii) Prevent the procedure from making pointers to such variables.
>
> Thus, I do not understand the following and cannot find any reference to
> it in the standard:
>
> $ cat pr20863a.f90
> PURE FUNCTION give_next(i)
>      TYPE node_type
>        sequence
>        TYPE(node_type), POINTER :: next
>      END TYPE
>      TYPE(node_type), POINTER :: node
>      TYPE(node_type), target  :: t
>      integer, intent(in)      :: i
>      node%next = t
> END FUNCTION
>
> THOMASP@PC-THOMAS-P /cygdrive/d/svn/prs
> $ /irun/bin/gfortran -c pr20863a.f90
>  In file pr20863a.f90:9
>
>      node%next = t
>                 1
> Error: Right side of assignment at (1) is a derived type containing a
> POINTER in a PURE procedure

According to my reading of section 12.6 of the F95 standard, this error 
is indeed incorrect; this is legal code.  The constraint at the bottom 
of page 212 lists a number of things that cannot be used as "the expr of 
an assignment-stmt in which the variable is of a derived type if the 
derived type has a pointer component...."  The list includes variables 
in common or accessed by host or use association, dummy arguments to 
pure functions, dummy INTENT(IN) arguments to pure subroutines, or 
objects storage associated with such variables.  This is quite 
definitely not an exhaustive list of all possible variable types, and 
local variables are not on it.

Further, it is quite implausible that there should elsewhere be a 
limitation that would make this illegal for local variables, and would 
not make that entire clause of 12.6 redundant.

> If t were a dummy argument, this would be correct would it not?

The presence of an error would be correct, yes.  However, if give_next 
were a subroutine rather than a function, and if t were declared 
INTENT(INOUT) or INTENT(OUT), then the code would again be legal.

Has a PR been filed for this?

- Brooks