To: J3                                                     J3/18-256
From: Dan Nagle
Subject: enums
Date: 2018-October-01


I Introduction

An enumeration type has been requested for several revisions
of the standard, but has never made the cut.  In part, this is
due to the proposers not agreeing on just what an enum should do
in Fortran.  Interoperability with C is the sole surviving use-case.

So while enums are wonderful things, we should focus on what
we want enums to do in Fortran before launching this expedition.


II What I have in mind

I propose that we clarify what we want the enums to do.
I hope these questions can be answered before proceeding too far.

Qs

Should enums provide n-way choice ?  (n > 2)

   This is the basic enum role.  I presume it remains a goal,
   whatever else is decided.

If enums are case expressions, must all select case branches be covered ?

   This is a correctness versus nanny issue.
   This issue interacts with anonymous enum values.

Are enums inter-convertible with integers ?

   Seems to me like a bug waiting to happen, but perhaps
   the added value outweighs the risks.
   What to do when an invalid integer value is magically converted?
   Should a conversion procedure be referenced to do so?

What new formats will enums need ?

   Will integer formats be used for enums?
   If so, it rather de-emphasizes the n-way choice aspect of enums.
   Otherwise, what is there?

What integer intrinsic procedures will enums use ?

   Which existing integer intrinsics should apply to enums?
   (Or, what is ABS(BLUE) ? )

Should enums provide kind values (per type) ?

   If real kind values were a different type than integer kind values,
   then errors of supplying a real kind value in an integer declaration
   could be caught.  And so on throughout the type system.

Should enums provide logical units ?

   Doing this allows processors to catch more errors earlier.

Should enums number the processor's error messages ?

   I'm not sure I see the value, but I have heard this mentioned.

Are enums allowed to subscript arrays ?

   One use of enums that has been proposed is to subscript arrays,
   as one would with an integer.  Is this to be supported?
   How to tie the enum definition to the array definition?
   (I presume this should work for dummy arguments as other arrays.)
   The advantages of this use-case appear to be in tension with allowing
   integer values to be assigned to enums.

Must all enum values have a name ?

   If enums are to subscript large arrays, it may be difficult to name
   each of 1000000 subscript values.  But some additional bounds checking
   might be provided if allowed, modulo integer assignments
   of unhelpful values to the enum entity.

What new intrinsics will enums need ?

   If anonymous enums are allowed, presumably next() and prev()
   procedures are needed, perhaps with first() and last() (or
   tiny() and huge() as per 18-114r1).  Are other intrinsics needed ?
   Are new intrinsics needed for specific use-cases of enums?

If integer-enum interconversion is allowed, will there be a intrinsic
to check that instances of an enum have allowable values?

   If I can make a mess of the enum values, can I check easily?


III What I have in mind

I hope we can decide what we want enums to do, and focus where
we add the most value.  I'm worried we're charging away without
a map, or even a good description, of the destination.

In short, the basic n-way choice appears to have been hunting
for other problems to solve.  Which do we wish to solve now?