On Fri, Jul 22, 2022 at 8:48 PM Jefferson Carpenter via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
> On 7/22/2022 5:26 PM, Edward Catmur via Std-Proposals wrote:
>
> > Also, how would you handle non contiguous enumerations?
>
> My initial thought would be that if an enumeration is non-contiguous,
> that's more for data marshalling (e.g. putting it into a PoD struct that
> can be serialized for I/O). It's not really relevant to the internal
> logic of the program. Even if an enumeration is non-contiguous, the
> number of elements of the array should equal the number of elements of
> the enumeration, and the array should be indexed by the enumeration.
> The index operator would have to map them to contiguous values.

Ignoring the immediate question of "why would anyone want this,"
there's something terribly confused about that description of the way
this ought to work.

Enumerations are numbers. That's just what they are: fancy ways of
writing constant integers, with varying degrees of type-safety
associated with those particular numbers. The value of an enumerator
is that number. That's what it means to get the value of an
enumerator.

Your description of the behavior of "non-contiguous enumerations"
seems to be that you want an enumerator name to *sometimes* mean "the
position of this enumerator within the enumeration". That's not a
thing in C++, and it really *shouldn't* be.

The position of an enumerator within an enumeration matters for
exactly one thing: how the value gets computed if one is not provided.
To try to do anything else with it is a really bad idea and makes for
a dubious interface.

Even if we were to decide that we need to access the index of an
enumerator, that should not happen *implicitly*. That is, it shouldn't
look exactly like accessing the *value* of an enumerator. There should
be a syntax associated with the operation, not merely assuming that it
works because you used it in the `[]` operator of some specific type.