(j3.2006) Lock variables

[Van Snyder]

Does C608 at [09-007:118:5-6] serve a purpose other than to try to make
a tiny almost invisible dent in the possibility to write a silly or
nonfunctional program?

"C608 A data entity that is or has an ultimate component of type
LOCK_TYPE in the intrinsic module ISO_FORTRAN_ENV shall be a coarray."

UTI 156 could be addressed simply by deleting the constraint.

09-143r2 advocated to put a revised version of this constraint in
13.8.2.16.

If a program locks a noncoarray LOCK_TYPE variable and then unlocks it,
so what?

If a program locks a noncoarray LOCK_TYPE variable and then locks it
again without a STAT= specifier, it gets a run-time error.  Again, so
what?

If a program locks a noncoarray LOCK_TYPE variable and then locks it
again with a STAT= specifier, it gets a nonzero status.  Again, so what?

If a program locks a noncoarray LOCK_TYPE variable and puts a
cosubscript on it, it gets a syntax error.  Again, so what?

Do we want to prohibit a lock variable from being an <output-item>?
It's silly to do it (which is only possible in an unformatted write
statement because it has private components).  This would be another
pointless prohibition, but in for a dime, in for a dollar.

Prohibiting lock variables in variable definition contexts (except as
the <lock-variable> in a LOCK or UNLOCK statement) was probably too big
a hammer: we prohibited lock variables from being actual arguments
associated with dummy arguments having intent(inout), from being pointer
objects in NULLIFY statements, and from being data pointer objects in
pointer assignment statements.  This makes the POINTER and TARGET
attributes pointless.  If this really was what we wanted, perhaps we
should also prohibit them from being dummy arguments (and therefore
actual arguments), and from having the ALLOCATABLE, POINTER or TARGET
attributes.  But then, why should we burden processors with more almost
meaningless constraints to check?  It would be simpler to prohibit them
from appearing *anywhere* except in declarations and as the
<lock-variable> in a LOCK or UNLOCK statement.

Perhaps we want only (1), the <allocate-object> from (11), INTENT(OUT)
from (12), and (13), in 16.6.7.  Everything else is prohibited by the
fact that lock variables are of derived type with private components.

An alternative is to remove them, because they don't seem to be ready to
go.  Put them in the "fancier coarray stuff" TR.

-- 
Van Snyder                    |  What fraction of Americans believe 
Van.Snyder at jpl.nasa.gov       |  Wrestling is real and NASA is fake?
Any alleged opinions are my own and have not been approved or
disapproved by JPL, CalTech, NASA, the President, or anybody else.