To: J3                                                     J3/18-262r2
From: Van Snyder & Malcolm Cohen
Subject: Pointer association context
Date: 2018-October-19


1. Introduction
===============

18-262 asked two questions, which subgroup answers as follows:

Question one:

    11.1.3.3p5 ([175:18-21] in 18-007r1) says that if a selector is not
    definable, neither the associate name nor a subobject of it shall
     appear in a variable-definition context.

    Should this also prohibit a pointer subobject from appearing in a
    pointer association context?

Answer one:

    This appears to be a defect in the standard.
    A new interpretation request appears below.

Question two:

    19.6.8 ([517:1-5] in 18-007r1) lists four pointer-association
    contexts.

    Intrinsic and defined assignment to a derived-type object that has a
    pointer component is not listed.

    Are these pointer-association contexts?

Answer two:

    No.  These are variable definition contexts, and therefore if a
    selector is not definable, it (and any subobject thereof) is not
    permitted according to the text quoted in question one.

    This is not a problem.


2. Interpretation request
=========================

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

NUMBER: F18/0003
TITLE: Pointer association of component of non-definable selector
KEYWORDS: Pointer association, Associate name
DEFECT TYPE: Erratum
STATUS: J3 consideration in progress

QUESTION:

Consider the following

  type :: T
    real, pointer :: X
  end type T

  type(t), external :: F
  real, target :: P

  associate ( A => F(42) )
    nullify ( A%X )             !***
    A%X => P                    !***
  end associate

The topic is whether the statements marked "!***" (the NULLIFY
statement and the pointer assignment statement) conform to the
standard.

11.1.3.3p5 ([175:18-21] of 18-007r1) has two requirements that are
relevant to this topic:
    "The associating entity itself is a variable, but if the selector
     is not a definable variable, the associating entity is not
     definable and shall not be defined or become undefined. If a
     selector is not permitted to appear in a variable definition
     context (19.6.7), neither the associate name nor any subobject
     thereof shall appear in a variable definition context."

With regards to the second sentence, neither NULLIFY nor a pointer
assignment statement is a variable definition context (19.6.7,
[516:12-30] lists fifteen variable definition context: neither
statement appears in the list.  Therefore it seems that this
requirement is satisfied.

With regards to the first sentence, the associate-name A "shall not
be defined or become undefined".  It appears that neither of these
statements cause A to be defined or become undefined, because
(a) An object of derived type is defined if and only all of its
    nonpointer components are defined (see 19.6.1p4, [511:11]).
    The pointer association status of the component A%X is thus
    irrelevant to the question of whether A is defined.
(b) Neither statement appears anywhere in the giant lists of "Events
    that cause variables to become defined" (or "undefined") in
    19.6.5 and 19.6.6.

Therefore we must reluctantly conclude that the requirements of the
first sentence also appear to be satisfied.

Against this, it is certainly true that the *value* of A is affected
by the statements in question: see 7.5.8 Derived-type values, which
states that the "component value" of a pointer component is its
association status, and
    "The set of values of a particular derived type consists of all
     possible sequences of the component values..."

However, there is no rule in 11.1.3.3 about changing the values, even
though it might seem contradictory that something that changes the
value of an undefinable object would be permitted.

So the question is, are the two statements standard-conforming?

ANSWER:

No, these statements were not intended to be standard-conforming.
The lack of an explicit rule is an error in the standard.
An edit is provided to correct this error.

EDIT to 18-007r1:

[175:21] 11.1.3.3 Other attributes of associate names, p5,
         After "variable definition context"
         insert " or a pointer association context",
making the whole paragraph read:
  "The associating entity itself is a variable, but if the selector
   is not a definable variable, the associating entity is not
   definable and shall not be defined or become undefined.  If a
   selector is not permitted to appear in a variable definition
   context (19.6.7), neither the associate name nor any subobject
   thereof shall appear in a variable definition context or pointer
   association context."
{Prohibit the marked statements.
 The extra context is only relevant to pointer subobjects, but this
 need not be stated explicitly.}

{This might appear to be an incompatibility since the explicit
 prohibition is missing from Fortran 2003 and 2008, and thus should
 require an edit to the "compatibility" subclauses in clause 4.
 However as it seems somewhat contradictory, it is argued that those
 standards do not establish an unambiguous interpretation of the code
 in question, so no compatibility issue arises.}

SUBMITTED BY: Van Snyder

HISTORY: 18-262r1 m217  Submitted

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

=== END ===