(j3.2006) 240 is wrong

[Van Snyder]

On Fri, 2014-10-03 at 15:02 +0900, Malcolm Cohen wrote:
> 2 v%c is not a variable
> 3 v%c is not a variable
> 4 v%c is not a variable

They aren't variables under the definition in 1.3.156, but it's not
obvious they're constants.  They're definitely not literal constants.
According to 6.3, "A constant is a named constant or a literal
constant....  A named constant is a constant that has a name; the name
has the PARAMETER attribute."  v%c is not a name; it's a designator.
Unlike the case for the INTENT attribute (5.3.10p6), 5.3.13 doesn't say
that subobjects of an object with the PARAMETER attribute have the
attribute.  6.3p1 doesn't say that a subobject of a constant is a
constant.  2.4.3.2.3p1 says a subobject of a constant is a portion of a
constant, but doesn't say that it IS a constant.  7.1.12p1(1) says "a
constant or a subobject of a constant."  The phrase "or subobject of a
constant" wouldn't be necessary if we said that in 2.4.3.2.3p1 or 6.3p1.

Perhaps we need to say in 6.3p1 that "A named constant has a designator
for which the first <part-name> has the PARAMETER attribute."  We don't
need to say "A named constant is a constant that has a..." because of
the first sentence of 6.3p1. We don't want to say that the designator is
a constant expression, because then things like A(I), where A is a
parameter and I is a variable, would not be constants -- there is a
difference between constants and constant expressions.  2.4.3.2.3p2
clearly contemplates this.  Then in 5.3.13 add "A subobject of an object
with the PARAMETER attribute has the PARAMETER attribute." (Compare to
5.3.10p6.)

There might be holes where we say "constant" instead of "constant
expression."  Better to define "constant" correctly and completely
instead of waving our hands and hoping we find all the holes.

> The flaw in ASSOCIATE is that the "associate-name" should have been 
> "associate-name or subobject thereof".  SELECT TYPE is peculiar in that here it 
> is a constraint, but has the same flaw (unsurprisingly).
> 
> All the references to variable definition context bar those two seem perfectly 
> fine.

> Obviously there is a different fix for this, and there is no incompatibility 
> since no interpretation was established for the broken usage.

Which repair is preferred?  Add "or a subobject thereof" in (13) or add

"(13a) a subobject of the variable appears in a variable definition
       context;"

14-136r1 proposed the "or a subobject thereof" fix in 16.6.7p1(13).  It
doesn't hurt to add the (13a) list item suggested in 14-240, and it
definitely covers more ground.  It might cover obscure cases such as the
failure to specify that a subobject of a constant is a constant, or that
a subobject of a parameter has the PARAMETER attribute.

It might be desirable to replace the first sentence of 8.1.3.3p2 with
"The associating entity is a variable if and only if the selector is a
variable" to avoid the appearance of a conflict with 1.3.156, or the
need of a caveat to avoid it.  This wouldn't be enough to solve the
entire problem, because the second sentence is still necessary, for
example if the selector has the INTENT(IN) attribute, because 8.1.3.2
doesn't say that the associate name has the same INTENT attribute as the
selector if the selector has an INTENT attribute.

During development of the ASSOCIATE construct I preferred to add "the
associate name has the same attributes as the selector," but that would
have made the associate name allocatable or a pointer if the selector
was, and we decided not to do that to maintain the parallel to argument
association.