(j3.2006) Simpler solutions for LOCK_TYPE problems

[Van Snyder]

The problems caused by C1302 are deeper than I had at first imagined.

I think they can be solved more simply than fiddling C1302 by deleting
it, and instead inserting "a coarray or coindexed object, or a
subcomponent thereof," after "shall be" in C853 (in 10-007r1, C850 in
14-007).

This avoids the problem of "subcomponent" in C1302.  It also allows
pointers of type LOCK_TYPE.  C1303 and C1304 would need adjustment to
prohihibit allocating or deallocating LOCK_TYPE pointers, and allowing
them in pointer association contexts.

I suggest the following:

In C1303 in subclause 13.8.2.16 LOCK_TYPE, after "<allocate-object>"
insert "if it is allocatable,, as the <pointer-object> in a NULLIFY
statement, as a <data-pointer-object> or <data-target> in a pointer
assignment statement, as an actual argument in a reference to a
procedure with explicit interface if it is a pointer and the
corresponding dummy argument has INTENT(OUT)".

In C1304 in subclause 13.8.2.16 LOCK_TYPE, after "<allocate-object>"
insert "if it is allocatable, as the <pointer-object> in a NULLIFY
statement, as a <data-pointer-object> or <data-target> in a pointer
assignment statement, as an actual argument in a reference to a
procedure with explicit interface if it is a pointer and the
corresponding dummy argument has INTENT(OUT)".

I earlier advocated to focus 16.6.7 more narrowly and exclusively on
variable association context, and relegate pointer association context
exclusively to 16.6.8.  That revision would greatly simplify C1303 and
C1304:

In C1303 in subclause 13.8.2.16 LOCK_TYPE, after "<allocate-object>"
insert "if it is allocatable,".

In C1304 in subclause 13.8.2.16 LOCK_TYPE, after "<allocate-object>"
insert "if it is allocatable,".

Similar but not identical adjustment would be needed to C601-C605 in the
TS.