To: J3 J3/21-189r1 From: Malcolm Cohen Subject: Interoperable enum types, additional specs/syntax/edits Date: 2021-October-22 Reference: 21-110r1, 21-121 1. Introduction An entity of interoperable enum type is not permitted as an argument to the INT intrinsic. The specs/syntax paper 21-110r1 clearly intended this to be allowed, but this is not explicitly stated. Secondly, there is no clear statement as to the set of values of an interoperable enum type, which could lead to confusion. Thirdly, interoperable enum types are not currently permitted in relational expressions. That would also appear to be an oversight. Fourthly, interoperable enum types are not currently permitted in SELECT CASE constructs. If we allow them in relationals, we should allow them here as well. This paper adds new specifications/syntax, and has edits. 2. Additional specifications (K) The INT intrinsic can be used to convert enum type to integer, basically returning the value with the same internal representation. (L) Interoperable enum types can appear in relational expressions; like assignment, only with the same enum type or an expression that has one of its enumerators as a primary. (M) Interoperable enum types can appear in SELECT CASE selectors and CASE statements. If the selector is an enum, a CASE expression may be of type integer as long as a primary is an enumerator. 3. Additional syntax The additional syntax follows directly from the specs. 4. Edits for 21-007r2 [89:1] Same subclause, p3 (beginning "If enum-type-name..."), append sentences: "The set of values of an interoperable enum type has a one-to-one correspondence with the set of possible values for the integer kind of its enumerators. The internal representation of each enum type value is the same as that of the corresponding integer." {Specify what the values are. Weasel-wording so that on a machine that is not two's complement, we don't get two values for zero. This gives us the self-explanatory term "corresponding integer value", which we will use to describe the semantics when needed.} [156:6] 10.1.5.1 Intrinsic operation classification, p1, "of an intrinsic type" -> "of a type". {Future-proof: This change is not needed, but improves the text anyway.} [156:9] Same subclause, p2, "of the intrinsic or enumeration types" -> "of the types". {Currently missing enum types. The types are stringently limited in the table, so it serves no purpose to limit them in the prose as well.} [156:23] 10.1.5.1 Intrinsic operation classification, p6, After "same enumeration type." insert new sentence "An enum relational intrinsic operation is a relational intrinsic operation for which one operand is of an interoperable enum type, and the other operand has the same type or is an integer expression involving an enumerator of that type." {Add a new class of intrinsic relation. I gave it a short name by omitting the word "interoperable".} [156:26+8] Same subclause, Table 10.2, ".EQ., ..." section, Change line "I I,R,Z L,L,L" to "I I,R,Z,N L,L,L,L" [156:26+12+] After line "E E L" insert line "N N,I L,L" [156:26+13] ".GT., ..." section, Change line "I I,R L,L" to "I I,R,N L,L,L" [157:0+3] After line "E E L" insert line "N N,I L,L" [157:0+8] Footnote section of table, After "both operands." insert new sentence "The symbol N stands for an enum type, where if the other operand is N, they have the same type, and if the other operand is I, the integer operand is an expression with a primary that is an enumerator of the enum type." {Insert into table. Declarative form "is" rather than "shall be" as these are a statement of what the intrinsic relationals are, we don't phrase the others as "shall" either.} [162:15+] 10.1.5.5.1 Interpretation of relational intrinsic operations, after p9 "An enumeration relational..." insert new paragraph "An enum relational intrinsic operation is interpreted as if all operands of enum type are converted to their corresponding integer values." {Semantics.} [201:9]. 11.1.9.1 Purpose and form of the SELECT CASE construct, C1148 "case-expr shall be of type", before "enumeration type" insert "enum or", making the whole constraint read "C1148 case-expr shall be of type character, integer, or logical, or of enum or enumeration type." {Permit enum types in SELECT CASE selectors.} [201:18] 11.1.9.1 Purpose and form of the SELECT CASE construct, C1150 "(R1142) For a given case-construct ...", sentence 1, after "case-expr" insert ", or in type conformance as specified in Table 10.8 if case-expr is of an enum type", making that sentence (not the whole constraint) read "For a given case-construct, each case-value shall be of the same type as case-expr, or in type conformance as specified in Table 10.8 if case-expr is of an enum type." {Permit enum types and compatible integer expressions in CASE statements. Reusing table 10.8 here is simpler than spelling it out.} [201:28} 11.1.9.2 Execution of a SELECT CASE construct, para 1, item (1), "type integer or character" -> "other types", making that item read "(1) If the case value range contains a single value v without a colon, a match occurs for type logical if the expression c .EQV. v is true, and a match occurs for other types if the expression c == v is true." {Specify semantics for the only case for which that is needed.} [402:35] 16.9.110 INT (A [, KIND]), p3 Argument, A, before "complex" insert "or", before "enumeration" insert "of enum or", making that argument read "A shall be of type integer, real, or complex, or of enum or enumeration type, or a boz-literal-constant." {Permit enum type as argument to INT.} [403:4+] 16.9.110 INT (A [, KIND]), p5 Result Value, after Case (iii) "If A is of type complex..." insert new Case "Case (iii+1) If A is of enum type, INT (A) has the value of the corresponding integer value." {Specify semantics of INT on enum type.} ===END===