To: J3 J3/21-164 From: Zach Jibben Subject: Restricted types: specifications and syntax Date: 2021-June-25 Reference: 20-121 20-106 19-214r1 19-161 19-135r1 18-265 1. Introduction =============== This paper contains the formal specifications & syntax for retricted types. 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: readonly components, and restricted types. Readonly components provide an access specification 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. Restricted 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 previously. Here is a summary; for more, refer to 19-135r1. Type restriction disables intrinsic assignment, allocation, deallocation, and finalization outside the module where that type is defined. It does not impose any restrictions on modifying components (pending straw vote results) -- that can be done independently with readonly components. This provides compile-time feedback when a client attempts to use a restricted derived type in a way the author intends to disallow, and gives the author the ability to provide custom alternatives to only those features they intend to allow. One example is a linked list, in which one may wish to disallow intrinsic assignment entirely. Otherwise, a client could inadvertently produce a shallow-copy. 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. A. A variable whose declared type is restricted shall not appear in a variable-definition context, except within the module wherein its type is defined. C. A local variable whose declared type is restricted is allowed outside the module in which the type is defined. - If some action is needed when the variable goes out of scope (and is thus destroyed unless it has the SAVE attribute) its type should have a final procedure. D. A local pointer of a restricted type is allowed outside the module in which the type is defined. - Otherwise use case 2.1 in 19-135r1 is not satisfied. E. Deallocating an object with a restricted declared type outside the module in which the type is defined is prohibited. - Otherwise for pointer, use case 2.1 in 19-135r1 is not satisfied. - Allowing it for remote/dummy allocatable would prohibit an allocatable variable in the module where the type is defined to be PUBLIC. - Allowing for local allocatable breaks rule (A) about not appearing in a variable definition context. F. Allocating an object with a restricted declared type outside the module in which the type is defined is prohibited. - Pointer would almost certainly leak memory. - Allowing for remote/dummy allocatable would have same problems as (E). - Allowing for local allocatable would have same problems as (E). J2. A dummy variable of a restricted type can be INTENT(IN) or INTENT(INOUT) in any procedure anywhere. A dummy variable of such a type shall not have INTENT(OUT) or unspecified intent except within the module in which the type is defined. K. Can modify (or allocate/deallocate) the *components* of a restricted type anywhere, provided the component is not subject to some other rule (e.g., a readonly component, or the component is itself of restricted type). - This is a point for discussion. Type restriction here would effectively disable intrinsic assignment, allocation, deallocation, and finalization *of the entire type* outside the module where it's defined, but would not impose any restrictions on the components. Readonly components would be used to enforce both. - This allows for the use case 2.3 presented in 19-135r1. - STRAW VOTE: Outside the module where the restricted type is defined, should component modification be allowed, or should type restriction only be relevant for direct operations on the type (allowing component modification)? (Allow component modification / disallow component modification / undecided) L2. Polymorphic allocatable assignment of a parent type without a restricted attribute is permitted even when the dynamic type has a restricted attribute. - This presents a loophole which may allow a programmer to write to a restricted type outside the module in which it is defined. However, subgroup did not like the alternative of disallowing the restricted attribute in extensions of unrestricted parent types. L3. No intrinsic assignment to an object whose declared type is restricted, or that has an ultimate component of restricted type, outside the module in which the restricted component is defined. (cf. 19-135r1) M2. A function defined outside the module may have a result variable of a restricted type. - This is same as ordinary local variables (case A). - The function result shall not be a pointer. - The function result will (hopefully) be finalised after its use. - Because intrinsic assignment is disallowed, the function result can only be used within an expression or as an argument. N2. A structure constructor outside the module in which the type is defined is not allowed. - This is disallowed for the same reason intrinsic assignment is disallowed. If you could use a structure constructor you could initialize an object with an invalid state. - This requirement is not in contradiction with M2, because a function outside the module which returns an object of restricted type still can only produce this object using methods provided by the module which defines the restricted type. O. A type may have a component of restricted type, and thereby inherits the restricted type attribute. - The protection rules apply to types with "potential subobject components of restricted type" not just types with immediate components of restricted type. See E, F, L3. P2. Extension of a restricted type is permitted. Q. An extension type may have a restricted attribute even if the parent type does not have a restricted attribute. Requiring the parent type to have be restricted is too restricted for many uses. S. An object with a restricted declared type is prohibited to be the target of an unlimited polymorphic pointer. - This rule applies even inside the module, even if the polymorphic pointer is private, because its target might thereafter become associated with a public polymorphic pointer. T. If an actual argument with a restricted declared type is associated with an unlimited polymorphic dummy, the dummy shall have INTENT(IN) or INTENT(INOUT) and shall not have TARGET (or POINTER, which implies TARGET). - If the dummy has TARGET it might become associated with an unlimited polymorphic pointer. - If the dummy has POINTER, its target might eventually become associated with an unlimited polymorphic pointer (see P.) 4. Syntax ========= One may add the RESTRICTED attribute to type definitions. One may independently control the access specifier of each component. type, restricted :: foo real, public :: a real, private :: b end type foo 5. Comments =========== 5.1 Alternative keywords straw votes There have been many keyword suggestions for this feature. Which should we go with? KEYWORD-1: RESTRICTED (YES/NO/UNDECIDED) KEYWORD-2: PROTECTED (YES/NO/UNDECIDED) KEYWORD-3: LIMITED (YES/NO/UNDECIDED) KEYWORD-4: CONTROLLED (YES/NO/UNDECIDED) KEYWORD-5: PERSISTENT (YES/NO/UNDECIDED) 5.2 Is an unrestricted type with only readonly components the same as a restricted type? A: No, an unrestricted type with all readonly components may be copied via intrinsic assignment, allocated, deallocated, and automatically deallocated outside the module wherein that type is defined. A restricted type disables all of these "type-level" definition contexts, and thus is more restrictive. This distinction is the motivation for having both readonly components and restricted types. In some cases a user may want to protect data in a type from any outside tampering, in which case a restricted type is warranted. In other cases, the user wants to ensure internal consistency in a derived type, but doesn't want to prevent the user from creating or destroying the type altogether. A user might also want to avoid expensive copies in getter procedures, which would be needed for private components. See the use-cases above. 5.3 Is a public component of a restricted type any different from a readonly component of a restricted type? A: The answer here is yes. Specification K allows modification of the components of a restricted type; i.e. the protection of a type really only restricts what can be done to the type as a whole. This is up for discussion, though, and could be changed (straw vote on K above). ===END===