To: J3 J3/21-168 From: Zach Jibben Subject: Protected components specifications and syntax Date: 2021-June-30 Reference: 20-121 20-106 19-214r1 19-161 19-135r1 18-265 1. Introduction =============== NOTE: This paper is the successor to 21-163. It incorporates the results of the straw votes; the name is changed to PROTECTED. It also incorporates feedback from discussion; PROTECTED/UNPROTECTED status is now independent of PUBLIC/PRIVATE access specification, and an UNPROTECTED keyword is added. This paper contains the formal specifications & syntax for protected components. This supersedes the specifications outlined by previous papers, as subgroup discussion revealed a more flexible feature set was needed to meet competing user requirements. Previous protected-components specifications fell into one of two camps. Papers 18-265 and 20-106 envisioned components inaccessible for *direct* modification outside the module in which the parent type was defined, but did allow a type containing a protected potential subobject to appear in a variable-definition context. These papers propose an access specifier roughly in-between PUBLIC and PRIVATE, by effectively prohibiting the name of a protected component from appearing in a variable-definition context, not protecting the variable itself. Other papers, 19-135r1, 19-161, 19-214r1, and 20-121 offered stronger protection, protecting variables themselves from being modified by virtually any means outside the module where that component was defined. This paper--and its partner paper--aims to satisfy both parties by teasing apart the competing goals into two separate features: protected components, and protected types. Protected components provide an attribute allowing code outside the module defining the type to read, but not *directly* modify components. These components will not impose any restrictions on the type containing them, beyond anything that might be imposed by the analogous PRIVATE or PUBLIC access specifiers. Protected types may be used to protect the data from appearing in variable-definition contexts. Although this is a formal syntax paper, the syntax will be defined by prose and by example, not by BNF, to aid comprehension. 2. Use Cases ============ Use cases have been presented in previous papers (18-265, 20-106, 19-214r1). Here is a summary; for more, refer to those papers. Protected components are useful in any situation where a user would want a derived type to expose a large dataset for reading, but does not want the client to modify the data except through provided procedures. They may also want the client to be able to store copies of these objects or deallocate them, while still controlling their internal consistency. Furthermore, a "getter" routine would require an expensive copy of the data, thus is suboptimal. Protected components allow the programmer to design a derived type API which reflects the intended use of certain objects -- exposing components without also giving the ability to modify them directly. For example, a CFD application's mesh may contain a large connectivity dataset: type :: mesh integer, allocatable, protected :: nbr(:) contains procedure :: init end type mesh A client must be able to create and initialize this mesh object through provided procedures. They might need copies to preserve some history. But the client absolutely must not be able to modify the nbr component directly. To summarize: subroutine ex1() type(mesh) :: m ! local variables allowed type(mesh), allocatable :: history(:) ! local allocatables allowed call m%init() ! modifying through module routines allowed print *, m%nbr ! reading protected components allowed allocate(history(1)) ! local allocation allowed history(1) = m ! intrinsic assignment allowed call read(m%nbr) ! passing protected component as intent(in) allowed call new_mesh(m) ! passing object as intent(out) or intent(inout) ! allowed m%nbr(1) = huge(1) ! FAIL: modifying protected component not allowed call change(m%nbr(1)) ! FAIL: intent(out) and intent(inout) not ! allowed on protected components m = mesh(nbr = [huge(1)]) ! FAIL: setting protected component ! via structure constructor not allowed allocate(m%nbr(1)) ! FAIL deallocate(m%nbr) ! FAIL ! automatic deallocation & finalization allowed ! even without a user-defined finalizer end subroutine ex1 3. Specifications ================= To help keep a record of how specs have changed and to aid discussion, specification labels are preserved from papers 20-121 and 19-214r1. B. The name of a protected component shall not appear in a variable-definition context, except within the module wherein its type is defined. G. A protected component or a subobject of a protected component can only be argument associated with an INTENT(IN) dummy, even if the referenced procedure is in the module in which the type is defined. H. A protected component or subobject of a protected component cannot be the target in a pointer assignment outside the module, as that would lose the protection. - Here I think it would be valuable to somehow expose an immutable reference, which could tie into the const-pointer proposals. I. A protected component or subobject of a protected component cannot be explicitly allocated or deallocated except within the module in which the type is defined. - Otherwise it's too easy to bypass the protection. - Allocating/deallocating a type containing a protected component is still permitted, provided it's not subject to some other rule. - Automatic deallocation on scope exit will occur as it would for any non-protected component. J1. A dummy variable of a type with a protected component can be INTENT(IN) or INTENT(INOUT) or INTENT(OUT) in any procedure anywhere, unless it's subject to some other rule. L1. No intrinsic assignment to a protected component or subobject thereof, outside the module in which the protected component is defined. (cf. 19-135r1) - This does not prohibit intrinsic assignment to a type containing a protected component. It is only meant to prevent the protected component from being modified by name. M1. A function defined outside the module may have a result variable of a type with a protected component. N. A structure constructor outside the module in which the type is defined is allowed if and only if no value is supplied for any protected component (otherwise this would subvert the module's control over what values are acceptable in the protected component). - This describes the same user-facing behavior for PROTECTED and PRIVATE components. However, the logic in the standard must be different. C7102 and 7.5.4.8p2 prevent a structure constructor from specifying a private component by restricting access to the name. For a PROTECTED component, the name is accessible, yet we still prohibit setting the value of such a component outside the module where the parent type is defined. P1. Protected components may be inherited through type extension. - Whether a component is inherited through type extension depends on if that component is PRIVATE or PUBLIC. R. Type-wide default protected component status, is provided. Default is UNPROTECTED, unchanged from the current standard. PROTECTED statement changes the default. Attributes in a component definition stmt confirm or override the default. - Default is UNPROTECTED, even if the type is extended from a parent whose default is PROTECTED. U. SEQUENCE and BIND(C) types shall not have protected components. - This includes any level of component selection, because non-SEQUENCE types are not allowed in SEQUENCE, and similarly BIND(C). AA. A component's status as PROTECTED/UNPROTECTED is independent of its access specifier PRIVATE or PUBLIC. BB. An UNPROTECTED keyword is provided, to override any type-wide default protected status. - Specifying UNPROTECTED here does not remove protection from any parent class's components. CC. Permit the default PROTECTED statement in the specification-part of a module, the UNPROTECTED keyword in type declaration statements and procedure declaration statements, and the UNPROTECTED statement. 4. Syntax ========= One may add the PROTECTED attribute to component definitions. The default PROTECTED statement, and the PROTECTED and UNPROTECTED keywords for components, are permitted only in the specification part of a module. type :: foo real, public, protected :: c real, protected :: a ! implied public by type default real, private :: b end type foo The requirement R allows a type-wide PROTECTED status, which may be overridden for an individual component using another access specifier. type :: foo protected real :: a ! public, protected real, private :: a ! private, protected real, unprotected :: b ! public, unprotected end type foo type :: bar private, protected real :: a ! private, protected real, public :: b ! public, protected real, unprotected :: c ! private, unprotected real, public, unprotected :: c ! public, protected end type bar ===END===