[J3] Scope of an implicitly declared variable in a construct

[Robert Corbett]

You explained to me the way this works and why before Fortran 2008 was approved.  If the variable is explicitly declared in the BLOCK construct, it is a construct variable and so the construct is its scope.  If the variable is implicitly declared, the variable is a local variable and its scope is the inclusive scope.  The reason you gave for wanting this behavior is that you wanted to be able to put BLOCK and END BLOCK around arbitrary code in a scoping unit without changing the behavior of the code.

Bob Corbett

> On Jul 5, 2019, at 5:15 PM, Van Snyder via J3 <j3 at mailman.j3-fortran.org> wrote:
> 
> I searched unsuccessfully for an answer to this question.
> 
> It's probably right where I looked (clause 19), but if it's there I
> didn't find it.
> 
> If a variable appears only within a BLOCK construct, is its scope that
> construct, or that construct's inclusive scope?
> 
> In particular, does it become undefined when execution of the construct
> completes?
> 
> This came up in a case where a colleague was using a BLOCK construct as
> a target for an EXIT statement, not as a device to declare a construct
> variable.  A variable was defined and referenced only within a DO
> construct within the BLOCK construct.  It was defined only if the index
> variable of an outer DO construct, that enclosed the BLOCK construct,
> had the value 1.  At least one processor complained that when referenced
> in the inner DO construct during iterations of the outer DO construct
> after the first one, it was not defined.  I.e., it's a construct entity
> of the BLOCK construct.
> 
>  do I = 1, ...
>    ....
>  b:block
>      ....
>      do J = 1, ...
>        if ( I = 1 ) x = 0.0
>        ! references to X.  Is it defined when I > 1?
>        if ( ... ) exit B
>      end do ! I
>      ....
>    end block b
>    ....
>  end do ! J
> 
> That processor was apparently assuming X was "an unsaved local variable
> of a BLOCK" and applying 19.6.6p1(23).
> 
> My recommendation to my colleague was IMPLICIT NONE, but that doesn't
> solve the problem in the standard (if there is one).
> 
>