On Sun, Oct 2, 2022 at 9:47 AM Magnus Fromreide via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
> On Sat, Oct 01, 2022 at 07:53:56PM -0400, Jason McKesson via Std-Proposals wrote:
> > On Sat, Oct 1, 2022 at 7:13 PM connor horman via Std-Proposals
> > <std-proposals_at_[hidden]> wrote:
> > >
> > > Keep in mind also that the max value of any enumerator may not be the maximum (or minimum) value the enum takes on. For example, an enum that is already a bitfield, or a type like std::byte.
> >
> > And what about enums that are treated as exactly what they are: a
> > value that can take on a fixed number of valid values?
> >
> > That's kind of the point of this. C++ has tools for treating enums as
> > bitfields or for treating enums as a hack for strong typedefs as
> > integers.
>
> Maybe that is the problem - the compiler is able to generate better code
> and diagnostics when it is told what the code is intended to do but here we
> have a single piece of code that can have multiple intents, should there be
> some way to tell the compiler what the intent is?

What you intend in one place is sometimes different from how it gets
used in another. It's often a matter of point-of-use, not an inherent
property of the type itself.

For example, you might read a bitfield value from a file and need to
validate that the user only specified bits you allow. So the question
you're asking is, for each set bit in the bitfield, is there an
enumerator that matches that bit's value. But since the enum is also a
bitfield, you want to be able to mash the bits together. That is, you
want values of the enumeration type to be distinct from enumerator
values.