To: J3                                                     J3/18-149
From: Van Snyder
Subject: Protection
Date: 2018-February-15

Reference: 18-119:2.5.3, 18-119:2.2.7

Attribute to protect targets of pointers.  See 18-119:2.5.3
===========================================================

This requires explicit interface, and requires that if the actual
argument has the attribute and the dummy argument is a pointer, the
dummy argument has the same attribute, or if the actual argument is a
pointer with the attribute and the dummy argument is not, the dummy
argument has INTENT(IN).  Prohibiting INTENT(OUT) and INTENT(INOUT) is
not enough.  Unspecified intent needs to be prohibited too.

Protected types.  See 18-119:2.2.7 (use case), 14-165r1 (proposed spec)
=======================================================================s

It's not obvious that pointers protected from changing their targets can
provide the desired functionality.

For example, a nonpointer object of a protected type could appear as the
LHS of a defined assignment, provided the assignment is bound to the
type or provided by the module in which the type is defined -- but not
as the LHS in an intrinsic assignment.  This is orthogonal to whether
the object is a pointer target.  A nonpointer object of a protected type
could appear as the actual argument corresponding to an INTENT(OUT) or
INTENT(INOUT) dummy argument, provided the procedure is bound to the
type or defined by the module that contains the type definition
(14-165r1 prohibits this).  This is orthogonal to whether the object is
a pointer target.  A nonpointer object of a protected type could appear
in an input list in a READ statement, provided defined I/O is used....

An object of protected type might be allocatable without the target
attribute.  Maybe it's a container represented by an array, and stepping
through the objects uses subscripts instead of pointers,  A pointer with
a protected target is irrelevant to this case.

Protected type as a term of art: See 14-165r1.
==============================================

Protected components
====================

A protected component cannot be changed outside the module wherein the
type of which it is a component is defined, except by procedures defined
for their type (as described above for protected types).  Even if we
provide for protected components, pointers that protect their targets
are nonetheless useful, not least because the target might be of
intrinsic type.  This should be specified as an attribute of the
pointer, not by an embellishment of INTENT.  We already use the word
PROTECTED to specify that the association status of a pointer accessed
by use association cannot be changed.  Another attribute, such as CONST
or LIMITED would be needed.

An object of a type with protected components can appear as the LHS of a
defined assignment, provided the assignment is bound to the type or
provided by the module in which the type is defined -- but not as the
LHS in an intrinsic assignment.