J3/17-163r1
To: J3
From: Malcolm Cohen & Bill Long
Subject: LOCK_TYPE and EVENT_TYPE requirements
Date: 2017 June 27


1. Introduction

The requirements on LOCK_TYPE and EVENT_TYPE require any variable of those
types to be a coarray (or a subobject thereof).  Presumably because one
cannot do anything useful with them otherwise.  However, because the
constraints fall short of requiring the entity to be a variable, there are
several useless things that can still apparently be done.

Existing compilers differ on whether these useless things are valid.

Secondly, the wording in the constraints uses the term "subcomponent".
This is inappropriate for a constraint since whether something is a
subcomponent varies at execution time.  The appropriate term must surely
be "potential subobject component".


2. Examples

Consider:
  MODULE unusable
    USE iso_fortran_env
    TYPE(lock_type),EXTERNAL :: FUN
  END MODULE
  PROGRAM useless
    USE unusable
    PRINT *,'Is this valid?'
    ! No reference to FUN.
  END PROGRAM

Since any actual function would need to have a result that is a variable,
and that variable is not permitted to be a coarray, the declaration of FUN
cannot be consistent with any possible Fortran function.  It is not
unlikely that a compiler would reject a declaration of an impossible
procedure, even if the program unit otherwise conforms to the standard.
(I would have to study the standard very carefully to say definitively
whether the useless program is conforming; my initial opinion is that it
is not, as no interpretation is established for FUN, i.e. it would be
caught by our "last resort" requirement.)

Consider:
  PROGRAM also_useless
    USE iso_fortran_env
    TYPE(lock_type),PARAMETER :: unlockable = lock_type()
    PRINT *,'Huh?',STORAGE_SIZE(unlockable)
  END PROGRAM

It is not possible to pass UNLOCKABLE as an actual argument to any
nonintrinsic procedure, as such a dummy argument would be a variable, and
therefore required to be a coarray, and thus the actual argument would
also be required to be a coarray.  But no requirement seems to have been
violated by the also_useless example.

Examples using EVENT_TYPE left as an exercise for the reader.

Finally, consider the example:
  MODULE post_final
    USE iso_fortran_env
    TYPE t
      PROCEDURE(lock_type),NOPASS,POINTER :: funptr => null()
    END TYPE
  END MODULE

It is hard to work out whether this is conforming or not.  Certainly no
target procedure for the funptr component can exist, which surely must
mean it is not conforming (the same as the first example).


3. Course of action

    Explicitly require named entities of these types to be variables, and
    thus coarrays.  Technically this appears to be an incompatibility with
    Fortran 2008 for LOCK_TYPE, so a compatibility clause addition would
    be needed (unless someone can find normative text that somehow
    prohibits it!).


4. Edits to N2123 (17-007r1)

[31:3+] 4.3.3 Fortran 2008 compatibility, end of subclause (after p5),
        Insert new paragraph
  "Fortran 2008 permitted a named constant to have declared type
   LOCK_TYPE, or have a noncoarray potential subobject component
   with declared type LOCK_TYPE; this document does not permit that."
{TECHNICAL CHANGE: incompatibility with F2008}

[441:32-] 16.10.2.10 EVENT_TYPE, between p2 and C1603, insert constraint
  "C1602a A named entity with declared type EVENT_TYPE, or which has a
          noncoarray potential subobject component with declared type
          EVENT_TYPE, shall be a variable.  A component of such a type
          shall be a data component."
{Clarification + TECHNICAL CHANGE.}

[441:33] Same subclause, C1603,
    Change "subcomponent"
    To     "potential subobject component",
making the whole constraint read:
   "C1603 A named variable with declared type EVENT_TYPE shall be a
          coarray.  A named variable with a noncoarray potential subobject
          component of type EVENT_TYPE shall be a coarray.".
{Editorial.}

[443:17-] 16.10.2.19 LOCK_TYPE, between p2 and C1606, insert constraint
  "C1605a A named entity with declared type LOCK_TYPE, or which has a
          noncoarray potential subobject component with declared type
          LOCK_TYPE, shall be a variable.  A component of such a type
          shall be a data component."
{Clarification + TECHNICAL CHANGE.}

[443:18] Same subclause, C1606,
    Change "subcomponent"
    To     "potential subobject component",
making the whole constraint read:
   "C1606 A named variable with declared type LOCK_TYPE shall be a
          coarray.  A named variable with a noncoarray potential subobject
          component of type LOCK_TYPE shall be a coarray."
{Editorial.}

===END===