To:         J3 Members                                       J3/16-152
From:       Van Snyder
Subject:    Unhelpful feature of associate names
Reference:  16-007
Date: 2016 January 27

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

It is unhelpful that the associate name can be polymorphic, but that it
cannot have the ALLOCATABLE attribute.  This precludes intrinsic
assignment to it if it is polymorphic.  See 7.2.1.2p1(1).

It is more useful that it be polymorphic than that it be nonpolymorphic
with the declared type of the selector.  Therefore it would be useful if
it could have the ALLOCATABLE attribute.

To allow intrinsic assignment, allow to specify that the associate name
has the ALLOCATABLE attribute, but only if the selector has the
attribute.

It would be weird to do this with the ALLOCATABLE attribute and not the
POINTER attribute.

In addition to enabling polymorphic intrinsic assignment, it would
enable allocation, deallocation, pointer assignment, and test for
pointer association of associate names.

This is a NEW FEATURE, and as such it is OUT OF ORDER at this time, even
though it corrects a serious blunder.

The purpose of this paper is to put notice of the problem into the
archive.  But if we want to correct the blunder now....

2. Proposed NEW FEATURE
=======================

There are two ways to address the problem.

(1) Allow a <block-specification-part> before the <block> in R802 and
R847.  Specify that an ALLOCATABLE statement that mentions an associate
name confers the ALLOCATABLE attribute, and that a POINTER statement
that mentions an associate name confers the POINTER attribute, but only
if the selector has the attribute.  In the absence of those statements,
the associate name does not have the attribute.  This is the way
argument association works.

Specify that an associate name has the ASYNCHRONOUS or VOLATILE
attribute if its selector has the attribute, but that, rather than iff,
the ASYNCHRONOUS or VOLATILE statement can add the attribute to an
associate name within the scope of the <block> (as in the BLOCK
construct), even if the selector does not have the attribute; there's no
way to subtract the attribute (nor is there a way to do this in the
BLOCK construct).  Other declarations in the specification part work as
they do for the BLOCK construct.

(2) Allow a reduced specification part that admits only ALLOCATABLE,
ASYNCHRONOUS, POINTER, and VOLATILE statements, and can only specify
their attributes for associate names, working as described above.  I
can't think of a reason to do this instead of the first proposal.
Indeed, a <block-specification-part> ought to be allowed before every
construct's <block>.

Both of these proposals are compatible with the current standard;
neither one would invalidate an existing program.

3. Draft edits for proposed NEW FEATURE
=======================================

[172:7+ R802] Insert a row in the definition of <associate-construct>:

"                      <block-specification-part>"

[173:5-6 8.1.3.3p1] Delete "and only if".

[173:6 8.1.3.3p1] Before "The associating entity" insert "If the
associating entity is a variable, the ASYNCHRONOUS or VOLATILE attribute
may be specified for it within the <block-specification-part>."

[173:6-7 8.1.3.3p1] Delete "and only if".

[173:7+ 8.1.3.3p1+] Insert a paragraph:

"The associating entity does not have the ALLOCATABLE or POINTER
attribute unless the attribute is specified within the
<block-specification-part>[; the attribute shall not be specified unless
the selector has the attribute.  The ASYNCHRONOUS or VOLATILE attribute
may be specified for an <associate-name> if the corresponding <selector>
is a variable.  The TARGET attribute may be specified for an
<associate-name> if the corresponding <selector> is not coindexed and is
not an array section with a vector subscript.]

{Material in the above paragraph in brackets might not be needed, in
light of constraints introduced in 8.1.4.}

If the associate name has the TARGET attribute and the selector does not
have either the TARGET or POINTER attribute, any pointers associated
with the associate name become undefined when execution of the construct
completes."

[174:10 C808+] Introduce constraints:

"C808a A <block-specification-part> shall not specify any attribute of
       an <associate-name> other than ALLOCATABLE, ASYNCHRONOUS,
       POINTER, TARGET, or VOLATILE."

"C808b The ALLOCATABLE or POINTER attribute shall not be specified for
       an <associate-name> if the corresponding <selector> does not have
       the attribute."

"C808c The TARGET attribute shall not be specified for an
       <associate-name> if the corresponding <selector> is coindexed or
       is an array section with a vector subscript."

"C808d The ASYNCHRONOUS or VOLATILE attribute shall not be specified for
       an <associate-name> if the corresponding <selector> is not a
       variable."

{Maybe C808d isn't needed -- or maybe it's even harmful.}

[174:14 8.1.4p2] Delete "the".  After "statements" insert ", or an
ALLOCATABLE, POINTER, or TARGET statement that specifies the attribute
for an associate name".  Replace "BLOCK construct" with
"<block-specification-part>".

[174:15 8.1.4p2] Delete "BLOCK".

[174:16 8.1.4p2] Replace "BLOCK construct" with
"<block-specification-part>".

[187:7+ R843] Insert a row in the definition of <select-rank-construct>:

"                      <block-specification-part>"

[190:2+ R847] Insert a row in the definition of <select-type-construct>:

"                      <block-specification-part>"