To: J3 J3/19-231 From: Van Snyder & Malcolm Cohen Subject: Formal Specifications for True Enumeration types Date: 2019-October-09 Reference: 18-114r1 18-256r1 19-216r1 19-230 1. Introduction This paper contains the proposed formal specifications for enumeration types (proposal US21). These have been extracted from 19-216r1, which mixes together requirements and specifications, and reworded. It is essential to refer to the Formal Requirements document when reading this paper. This paper does not contain the formal syntax of the feature. Any syntax in this paper is illustrative. 2. Formal specifications 1. [A] An enumeration type name shall be a class one name, and shall be treated the same as (other) derived type names. 2. [A] An enumeration type shall have at least one enumerator. (Otherwise it would have no possible value.) 3. [A] An enumeration type is a derived type that is not a structure type. It has no type parameters. COMMENT: Type parameters just don't seem to make sense for enumeration types. 4. [B] An enumeration type is extensible and not interoperable. The type definition shall have no type-bound-procedure-part. COMMENT: We could permit a type-bound procedure part now, or permit one in the future. The semantics of having type-bound procedures would seem to make sense; however, in the interests of keeping this feature to a manageable size, we should not allow it now. 5. [B] In consequence, an enumeration type cannot be a SEQUENCE or BIND(C) type, and that enumeration type definitions in different scoping units will produce different enumeration types, even if the type definitions themselves are textually identical. Furthermore, a SEQUENCE or BIND(C) type shall not contain a component that is of enumeration type. And therefore also cannot appear in EQUIVALENCE or COMMON. 6. [B] A non-extended enumeration type definition shall list all the enumerators in order; the ordinal number of an enumerator is its position in the list. 7. [B] An extended enumeration type definition inherits the enumerators from its parent type, and acts as if its list were appended to the parent type's list. 8. [B] Extending an enumeration type produces another enumeration type; extending a structure type cannot produce an enumeration type. 9. [A] The enumerator values of an enumeration shall have an internal representation that is the same as a processor-dependent integer kind, with the value being the same as the ordinal number of the enumerator. COMMENT: This is actually merely implementation advice, so maybe this should be a "should" not a "shall". It is conceivable that a processor might want to put some extra info into an enum type, e.g. it might have its name, or where it was defined, etc. 10. [B,D] If the parent type has a default value, an extension may specify a different default value. If it does not specify a value, it inherits the default value from the parent type. 11. [F,G] An attribute on the type definition determines whether the enumerator names are declared as class one names; for example, NAMED_ENUMERATORS would declare all of the enumerator names, and UNNAMED_ENUMERATORS would declare none of them. In either case, the alternative syntax for denoting an enumerator qualified by the enumeration type name shall be available. 11.ALTERNATIVE ONE: Enumerator names are always declared as class one names. Enumeration type definitions in the same scope shall not have enumerators with the same name. Accessing enumerator names via use association works according to the usual rules: if a name is unique it is accessible, and if it is not unique it is not permitted to be accessed. 11.ALTERNATIVE TWO: Some magic shall happen so that enumerator names are magically declared if and only if they would be unique. 12. [F,G] Enumerator names that are class one names have all the usual class one name rules applied; in particular, they must not clash with any other class one name, unless they are unused and accessed by use association. 13. [F,G] Regardless of the syntax used to denote an enumerator, it is a constant expression. If the syntax is a class one name, it is a named constant. 14. [F,G] Accessing the name of an enumeration type by use association does not by itself make any of its enumerator names available. That is, USE,ONLY:TYPENAME only accesses TYPENAME. The alternative syntax for denoting an enumerator shall be unaffected by the accessibility of a class one enumerator name. 15. [F,G] The alternative syntax for denoting an enumerator shall involve the enumeration type name and no other class one name. If the enumeration type name is inaccessible, this syntax shall not be available. 16. [F,G] The accessibility of an enumerator name shall be determined either by explicit specification, or the operation of some default. The same accessibility applies both to the enumerator name as a class one name (if such exists) and to the alternative denotation syntax. COMMENT: It is conceivable to have the accessibility as a class one name decoupled from the accessibility of the alternative denotation syntax. PRIVATE (class one) and PUBLIC (qualified) seems to make sense, though it is almost identical to not having a class one name at all; in that sense, it could be an alternative to controlling the class one name existence. However, PUBLIC (class one) and PRIVATE (qualified) does not make any sense, though it might be useful for confusing people. COMMENT: The default accessibility of an enumerator could be the module's default accessibility or the accessibility of the enumeration type name, and/or controlled by a separate statement within the type definition. This is a matter of syntax. 17. [H] A variable of enumeration type shall be initialised only by a value of that enumeration type. 18. [H] Default initialisation of components that have enumeration type shall be allowed. If no default initialisation is specified, the component is nonetheless default-initialised to the default value for the enumeration type (if any). 19. [I] In intrinsic assignment involving enumeration type, the type of the variable shall be an extension type of the expression. 20. [K] The conversion mechanism from enumeration to integer shall be the intrinsic function INT. 21. [K] The conversion mechanism from integer to enumeration shall be the type constructor; note that this is NOT a structure constructor. As the ordinal value is not a component, it does not have a name. OPTION 1: An out of range integer value causes error termination. OPTION 2: The integer value is "clamped" to the range of ordinals, thus always producing a valid enumeration value. 21.ALTERNATIVE: The conversion mechanism from integer to enumeration shall be a pure function, implicitly defined by the type definition, with the same name as the type. Although this looks like a structure constructor, it is not a constructor but a function with named arguments. There shall be some optional way of returning an error status to the caller, with error termination on error if missing. The function shall be usable in constant expressions. OPTION: The function shall be elemental. 22. [L] The mechanisms for enquiring the first/last enumeration values shall use an entity of that enumeration type. The result is a constant expression. 23. [M] The mechanisms for producing the "next" and "previous" values shall cause error termination if an error occurs. ALTERNATIVE ONE: These mechanisms "clamp" the result to the enumeration range. ALTERNATIVE TWO: These mechanisms have some optional way of returning an error status to the caller, with error termination on error if missing. 24. [N] Formatted output of enumeration values produces the name of the enumerator in upper case (not qualified by the type name). Formatted input shall accept both lower case and upper case as equivalent. 25. [N] Unformatted files use a processor dependent representation. 26. [O] When a SELECT CASE expression is of enumeration type, the CASE values shall be type-compatible (that type or an ancestor thereof). CASE ranges shall be available; the ordinal number of the second value shall be greater than or equal to the ordinal number of the first. 27. [C,P] If a DO index variable is of enumeration type, the variable shall have its type explicitly declared on the DO statement, limiting its scope to the DO or DO CONCURRENT construct. 27.CONSEQUENCE: This requires the enumeration type to be accessible, *unless* the TYPE_OF(...) feature makes it into F202x. The remaining specifications do not refer to any particular requirement. 28. Generic resolution shall treat different enumeration types as different types, and different from any other type. 29. A variable of enumeration type shall not be polymorphic. 30. Argument association shall treat different enumeration types as different. 31. [C] TRANSFER into an enumeration type should be limited to values that resulted from a TRANSFER out of the same enumeration type. ===END===