J3/15-253
To: J3
From: Malcolm Cohen
Subject: Interp F08/0109 revisited
Date: 2015 October 15

----------------------------------------------------------------------

NUMBER: F08/0109
TITLE: LOCK_TYPE and unlimited polymorphic
KEYWORD: LOCK_TYPE, unlimited polymorphic
DEFECT TYPE: Erratum
STATUS: J3 consideration in progress

QUESTION:

Assume type LOCK_TYPE from the intrinsic module ISO_Fortran_Env is
available.

Q1. Is allocation of X%C permitted?

  TYPE t
    TYPE(LOCK_TYPE),ALLOCATABLE :: c
  END TYPE
  TYPE(t) :: x[*],y[*]
  ALLOCATE(y%c)
  ALLOCATE(x%c,SOURCE=y%c)

Q2. Is allocation of C permitted?

  class(*), pointer :: C
  type(lock_type), intent(in) :: L[*]

  allocate ( C, source=L )

Q3. Is allocation of C permitted?

  class(*), pointer :: C

  allocate ( LOCK_TYPE :: C )

Q4. Is pointer assignment to C permitted?

  class(*), pointer :: C
  type(lock_type), intent(in), target :: L[*]

  c => L

Q5. Is this ALLOCATE statement conforming?

  CLASS(*),ALLOCATABLE, SAVE :: C[:]
  TYPE(LOCK_TYPE),      SAVE :: X[*]
  ALLOCATE(C,MOLD=X)

ANSWER:

A1. Allocation of X%C is not intended to be allowed.  An edit is
    supplied to correct the requirements on allocation of LOCK_TYPE.

A2. Allocation of C is not intended to be allowed.  An edit is
    supplied to correct the requirements on allocation of LOCK_TYPE.

A3. This allocation of C is permitted.  It cannot violate C1302 because
    that is a syntax constraint.  Only things that are statically
    detectable static properties of the program source text can be
    syntax constraints.  That means that "type" in C1302 can only mean
    "declared type".

    C is CLASS(*) so has no declared type and therefore cannot
    violate C1302.

    Edits are given to fix C1302 to say "declared type" explicitly to
    avoid this confusion.

    Note that it is impossible to actually use the allocated target of
    C in any useful fashion; SELECT TYPE cannot access it because the
    associate-name would be a named lock variable, but it is not a
    coarray so that would not be allowed.

    So this is permitted, but useless, and because it is useless it is
    also harmless.  A future revision could disallow this without the
    concomitant incompatibility inconveniencing any programs.

A4. Pointer assignment to C is permitted.

    As in A3, this is useless but harmless.  A future revision could
    disallow this without the concomitant incompatibility
    inconveniencing any programs.

A5. This statement was intended to be permitted.  An edit is supplied
    to correct the requirements.

EDITS:

[6:7+] After definition 1.3.33.2 parent component, insert new term
  "1.3.33.2a
   potential subobject component
   nonpointer component, or potential subobject component of a
   nonpointer component (4.5.1)".

[127:8-9] 6.7.1.1 Syntax, C642,
          Change "C_PTR," to "C_PTR or"
          Delete ", LOCK_TYPE ... LOCK_TYPE".

[127:9+] Insert new constraint
  "C643a (R627) If SOURCE= appears, the declared type of <source-expr>
         shall not be LOCK_TYPE or have a potential subobject
         component of type LOCK_TYPE."

[127:18-19] 6.7.1.1, p4,
  "If" -> "If an ALLOCATE statement has a SOURCE= specifier and an",
{There is no problem with MOLD=.  "subcomponent" works ok here because
 we have an object not a type.}

[399:17] 13.8.2.16 LOCK_TYPE, C1302
     "variable of type LOCK TYPE"
  -> "variable with declared type LOCK_TYPE".

SUBMITTED BY: Van Snyder

HISTORY: 14-164    m204  F08/0109 submitted
         14-164r3  m204  As amended, passed by J3 meeting
         14-258    m205  Failed the J3 letter ballot #31 14-233r1
         15-nnn    m208  Revised

----------------------------------------------------------------------