ISO/IEC JTC1/SC22/WG5 N1526

	            Enum has been emasculated

                          Richard Maine

In the process of removing typealias, paper j3/03-119r1 redefined
enum so that it no longer depended on typealias.  Unfortunately,
this redefinition was done with an ax; it just deleted the part
of enum that formerly referred to typealias.  In my opinion, this
so emasculates enum as to make it an embarrassment - it cut out
the most important part of enum.

Enum in the current draft is fundamentally a feature for C
interop; we deleted the non-BIND(C) variant of it.  As an
interop feature, the fundamental point of enum is to determine
the appropriate integer kind that would interoperate with the
corresponding C enums....and that's the part that got cut out.
What remains is just the syntactic sugar of having a different
syntax for defining a set of integer named constants.

Without type aliases, we need to use a kind type parameter.
That would be ok, but the enumeration doesn't give us one.

One can still deduce the kind, but only by using an indirection,
the silliness of which just points out that the current feature
design is flawed.  You have to pick one of the enumerators at
random and do an inquiry on it.  For example, if we want to
declare a variable appropriate for the enumeration given in
Note 4.66 on page 65 (after it is corrected to actually conform
to the bnf), we need to do something like

  integer, parameter :: pc_kind=kind(red)
  integer(pc_kind) :: some_variable

or, if we had no other need for pc_kind, we could shorten it to

  integer(kind(red)) :: some_variable

This is just silly.  What is special about red here?  Nothing,
but we need to choose one of the enumerators at random.

The enumeration should directly define a parameter for this
purpose instead of requiring us deduce it by inquiring about one
of the enumerators.  Syntax TBD.  One obvious possibility is
just to put the kind parameter name in the same place as we
used to have the typealias name.  I suppose that in principle
it could even be optional, though it seems likely to be wanted
almost all the time in practice.

In my opinion, if we should either fix this problem or delete
enum entirely (which we voted not to do at the previous meeting).
As is, it's flaws are so blatant as to be an embarassment