J3/14-142r1
To:        J3
Subject:   Coarray pointers feature proposal
From:      Van Snyder
Date: 2014 May 29
Reference: 14-138

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

A pointer can be associated with a coarray, but it cannot then be
coindexed.  This is unhelpful.

Paper 14-138 advocates to allow the <lock-variable> in a LOCK or UNLOCK
statement to be a pointer, and puts constraints on LOCK_TYPE in a
pointer assignment statement to ensure it is associated with a coarray.
This would work to access the local image, but a pointer cannot be
coindexed.  Not being able to coindex the pointer in a LOCK or UNLOCK
statement is unhelpful.

The proposal in 14-138 covers similar but more narrowly focused ground.
Paper 14-138 advocates to remove C1302, and moves the requirement for a
<lock-variable> to be a coarray from the declaration of the
<lock-variable> to its use in a LOCK or UNLOCK statement.  The
objectives of 14-138 would be achieved by this proposal, in a different
way.  They need not both be pursued.

Some of my comments on the ballot for N2007/14-130 concerning EVENT_TYPE
would also be addressed by this proposal.

2. Proposal
===========

Allow the POINTER attribute and <deferred-coshape-spec> to coexist.

The pointer itself is not accessible from other images.  When a coarray
pointer is coindexed, it is the target that is coindexed.

If a pointer in a pointer assignment statement is a coarray, the target
shall be a coarray.

C724 prohibits a <data-pointer-object> in a pointer assignment statement
from being coindexed.  Don't change it.

It is not necessary to tackle cobounds or corank remapping at this time.

Prohibit to allocate or deallocate coarray pointers.

Allow pointers of LOCK_TYPE in pointer-association contexts.

3. Draft edits to 14-007r1, to estimate the scope of the project
================================================================

[39:15+ 2.4.7p4+] Insert a paragraph (or append to p4):

"When a coindexed pointer is referenced, it is the coindexed target that
is referenced.  The pointer on the image specified by the cosubscripts
is not accessed."

{In light of 6.2p2 at [119:17-19] and C720a below, it's not necessary
here to say it shall be associated with a coarray target.}

{Maybe this belongs at [122:2+ 6.4.3p1+]}

[90:18+ C509+] Insert a constraint:

"C509a (R503) If <coarray-spec> appears and the object has the POINTER
        attribute, <coarray-spec> shall be <deferred-coshape-spec>."

[93:25 C526] After "ALLOCATABLE" insert ", POINTER, ".

[102:15 C552] Delete ", and shall not be a coarray".

[128:25+ C629+] Insert a constraint:

"C629a (R632) An <allocate-object> shall not be a coarray pointer."

[160:18+ C720+] Insert a constraint:

"C720a (R733) If <data-pointer-object> is a coarray, <data-target> shall
       be a coarray having the same corank as <data-pointer-object>, and
       shall not be a subobject of a coarray."

{Maybe the prohibition against subobject is unnecessary.}

[161:35+ 7.2.2.3p7+] Insert a paragraph:

"If the pointer object is a coarray, and the target is not a
disassociated pointer, the cobounds of the pointer are assumed from
those of the target."

[402:25 C1303, 402:28 C1304] After <allocate-object> in both
constraints, insert ", as a <data-pointer-object> or <data-target> in a
<pointer-assignment-stmt>, as a <pointer-object> in a NULLIFY statement,
as an actual argument in a reference to a procedure with explicit
interface if the corresponding dummy argument has the POINTER attribute".

{These would be simpler if 14-139 were pursued; the proposal in that
paper more precisely separates variable definition context and pointer
association context.}