To: J3 J3/22-168r1 From: Malcolm Cohen Subject: Component specification expression rules Date: 2022-July-18 1. Introduction Prior to Fortran 2003, expressions in a component definition statement were required to be constant expressions. That all changed with Fortran 2003 and parameterised derived types, where expressions for array bounds and length type parameters were permitted to reference length type parameters of the type being defined. To make exposition easier, instead of describing these as their own class of expression, or as "constant expressions plus length type parameters", they were described as specification expressions plus constraints to achieve the goal (constant expr + length type params). In particular, references to variables are not permitted, nor are intrinsic functions that depend on runtime state such as ASSOCIATED, and any specification inquiry is required to be a constant expression. However, since then, additional intrinsic functions have been added that are appropriate for general specification expressions, but inappropriate for component specification expressions. For example, THIS_IMAGE() is permitted in a general specification expression, but as it varies at runtime, it is inappropriate for a component specification. This paper proposes edits to fix this problem. 2. Rationale We want declarations like TYPE(T) X TYPE(T2(123,455)) Y to act similarly to declarations like REAL X CHARACTER(12345) Y i.e. the possibility of any variability in the layout or size of a variable is signalled on the declaration, not hidden in the type definition. The whole rest of the language depends on this. 3. Notes Actually, this was already wrong in Fortran 2003, as COMMAND_ARGUMENT_COUNT was not excluded. The additional restrictions appear twice, once for length type parameters, once for component array bounds. Thus this paper proposes introducing a new term "component specification expression" with a single definition. 4. Edits to 22-007r1 [18:36+] After 3.131 insert new sub-term "3.131.1 component specification expression specification expression satisfying additional requirements specified in 10.1.11, thus being suitable for use in specifications in a component definition statement" {Note: Hyperlink component definition statement. Try to hyperlink 10.1.11 not to the beginning of that subclause, but to the extra requirements paragraph.} [72:35-38] 7.5.4.1 Component definition statement, C755, Change "specification expression... variable" to "component specification expression" making the whole constraint read "C755 (R740) Each bound in the explicit-shape-spec shall be a component specification expression." {Hyperlink new defined term.} [73:5-8] Same subclause, C759, Change "specification expression... variable" to "component specification expression" and delete the "(R736)" that is redundant with the wording, making the whole constraint read "C759 Each type-param-value within a component-def-stmt shall be a colon or a component specification expression." {Again, hyperlink new defined term.} [168:8+] 10.1.11 Specification expression, p8+ Between paragraph 8 and NOTE 2, insert new paragraph "A component specification expression is a specification expression in which - there are no references to specification functions, - there are no references to the intrinsic functions ALLOCATED, ASSOCIATED, COMMAND_ARGUMENT_COUNT, EXTENDS_TYPE_OF, GET_TEAM, NUM_IMAGES, PRESENT, SAME_TYPE_AS, TEAM_NUMBER, or THIS_IMAGE, - every specification inquiry reference is a constant expression, and - the value does not depend on the value of a variable. A reference to the intrinsic function TRANSFER in a component specification expression is permitted only if each argument is a constant expression and each ultimate pointer component of the SOURCE argument is disassociated." {Note: Hyperlink everything possible. Index as a definition of "component specification expression".} ===END===