To: J3                                                     J3/19-107
From:    Van Snyder
Subject: Irregularities (index variables)
Date: 2019-January-16
Reference: 18-242

Introduction
============

To reduce surprises, especially for newcomers to (modern) Fortran, it
would be helpful if facilities that have similar purposes had similar
details.

The example under attention here is index variables.

In <ac-implied-do-control>, the <ac-do-variable> can be preceded by
<integer-type-spec> ::.

In <data-implied-do>, the <data-i-do-variable> can be preceded by
<integer-type-spec> ::.

In <concurrent-header>, the <concurrent-control-list> can be preceded by
<integer-type-spec> ::.

This is not possible in <loop-control> in <do-stmt> or <io-implied-do>.

18-242 was rejected by /JOR on Monday, October 15 without plenary
discussion.  The minutes include the remark

   Seemingly syntax-sugar change would have semantic effect.
   No value seen.

There has in the interim been e-mail discussion that suggests that
plenary discussion might have reached a different decision.

Proposal
========

To eliminate this irregularity

(1) <integer-type-spec> :: should be allowed before the <do-variable> in
    <loop-control> in <do-stmt>, with the additional effect that the
    <do-variable> becomes a construct entity.  Because a <do-variable>
    with <integer-type-spec> :: is a construct entity, there would be no
    harm to allow it to have the same name as the <do-variable> of an
    enclosing DO construct.

(2) <integer-type-spec> :: should be allowed before the <do-variable> in
    <io-implied-do-control>.  This would have no semantic effect because
    the <do-variable> is already defined in 19.4p1 to be a statement
    entity.  Because there might be more than one <do-variable> within
    the same statement, and there is no concept of "the scope of an
    <io-implied-do>," a <do-variable> with <integer-type-spec> :: should
    not be allowed to have the same name as the <do-variable> of an
    enclosing <io-implied-do>.

Syntax options for item (1)
===========================

There was some objection to simply inserting <integer-type-spec> ::
before the <do-variable> in <loop-control> in <do-stmt> because this
causes the <do-variable> to become a construct entity.  Some
correspondents remarked that this is a problem.

Alternative 1: Allow inserting <integer-type-spec> ::
before the <do-variable> in <loop-control> in <do-stmt> without
additional syntax to warn that the <do-variable> becomes a construct
entity.

Alternative 2: Allow inserting <integer-type-spec> :: before the
<do-variable> in <loop-control> in <do-stmt>, with additional syntax,
such as parentheses around <loop-control>, to warn that the
<do-variable> in <loop-control> in <do-stmt> becomes a construct entity.

Use Cases
=========

allowing

  do integer :: I = 1, 10
    ! blah blah blah
  end do

or

  do ( integer :: I = 1, 10 )
    ! blah blah blah
  end do

avoids requiring

  block
    integer :: I
      do I = 1, 10
      ! blah blah blah
    end do
  end do

(See earlier papers advocating that all constructs ought to have a
<block-specification-part>).

Editorial effects
=================

In the discussion of the <do-variable> in <loop-control> in <do-stmt>,
it would be necessary to specify that if <integer-type-spec> :: appears,
the <do-variable> becomes a construct entity.  This should be in 19.4p3,
not in 11.1.7.2, for consistency with discussion of the scope of the
<index-name> in a <concurrent-header>, which is specified to be a
construct entity in 19.4p3, not in 11.1.7.2.  A paragraph similar to
19.4p6 will also be needed.

In the discussion of the <do-variable> in <io-implied-do-control>, it
would be necessary to add paragraphs similar to 7.8p2-3.  No new
discussion will be necessary in 19.4 because the <do-variable> in
<io-implied-do-control> is already specified to be a statement entity.