To: J3                                                     J3/21-111
From:    John Reid
Subject:  US-21 Typed enumerators
Date: 2021-February-21
References: N2165, N2170, 18-256r1, 19-216r, 19-229, 19-230r2

INTRODUCTION

US-21, as described in N2165, was approved for inclusion in F202x in
resolution T1 of N2170. N2165 says "18-256r1 contains extensive
discussion of this feature along with a list of still-open questions."
WG5 accepted that it was a good idea to add typed enumerators and
delegated the task of working out the details to J3.

19-216r1 was adopted on the last day of the Tokyo meeting and was
superseded by 19-230r2, passed at meeting 220 (Oct 2019). This contains
15 formal requirements. An enumerator has an "ordinal number" which is
its position in the type declaration and conversions are available from
an enumerator to an integer and vice versa. However, an enumerator
has no other value.

There is much experience in other languages of enumerators with values
and they are used widely in applications. They provide a way to group
named constants of a single type and kinds. Several examples are given
in 19-229. 19-230r2 states that an enumeration type can be emulated with
the derived type
    TYPE enum
      INTEGER,PRIVATE :: value
    END TYPE
Corresponding to this, I believe that an enumeration type with values
of a given intrinsic type and kinds can be emulated with
    TYPE enum
      INTEGER,PRIVATE :: ordinal
      <intrinsic-type-spec>,PRIVATE :: value
    END TYPE
Of course, a compiler would not do exactly this in an implementation,
but it gives an indication of the likely implementation cost. It would
also be necessary to define which intrinsic operations (such as <) and
which intrinsic functions (such as max) would be available with objects
of enumeration type replacing the corresponding objects of intrinsic
type. For safety, all these objects would be required to be of the
same enumeration type. Any mixing of types would be available only via
explicit conversions to intrinsic type using the functions INT, REAL,
etc.

This is a request for further consideration of the idea of allowing
an enumeration type to declare an underlying intrinsic type and kinds,
with constants of this type and kinds for each enumerator. Without
it, we will fail to satisfy a significant use case of access to a
constant of a group in a safe manner -- no accidental access to
another constant. For more detail, see 19-229.