On Mon, 10 Jul 2023 at 12:25, David Brown via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> On 10/07/2023 10:53, Alejandro Colomar via Std-Proposals wrote:
> > Hi Jonathan!
> >
> > On Mon, Jul 10, 2023, 10:03 Jonathan Wakely via Std-Proposals
> > <std-proposals_at_[hidden] <mailto:std-proposals_at_[hidden]>>
>
> > wrote:
> >
> >
> >
> > On Mon, 10 Jul 2023, 08:15 Frederick Virchanza Gotham via
> > Std-Proposals, <std-proposals_at_[hidden]
> > <mailto:std-proposals_at_[hidden]>> wrote:
> >
> > Given the following enum:
> >
> > enum MyEnum : int {
> > eInvalid = 1,
> > eFrog = 2,
> > eGoat = 4,
> > eFish = 8,
> > eMonkey = 16,
> > };
> >
> > I propose that:
> >
> > std::enum_max<MyEnum>
> >
> > would evaluate to 16, and that:
> >
> > std::enum_min<MyEnum>
> >
> > would evaluate to 1.
> >
> >
> > Why?
> >
> > This is perfectly valid:
> > auto e = (MyEnum)INT_MAX;
> > And similarly for INT_MIN and 0 etc.
> >
> >
> > Heh, I learnt something new today. I didn't know about this. Would you
> > mind pointing to where this feature is described in the standard? I'm
> > curious about it.
> >
> > Regarding the proposal, I find it more readable and portable, since
> > casting to an enum type in C doesn't do that magic. But since the
> > feature already exists, I wouldn't support yet another way of doing the
> > same thing.
> >
>
> Just to be clear - "auto e = (MyEnum) INT_MAX;" is legal C++, but it
> does not do what the OP wanted. It gives you a variable of type
> "MyEnum" with value INT_MAX, because an "enum" type in C++ is basically
> just a different name for an "int" (or other underlying integer type).
> The language does not restrict the values that can be stored in an
> enumerated type, beyond the limits of the underlying integer type.
>

That's true if the enum has a fixed underlying type. If it does not have a
fixed underlying type, the valid values are only those which can be
represented in the bits required by the enumerators. For the OP's example,
the enumerators require five bits (to represent the eMonkey enumerator with
value 16) so the valid values of the enum are all values representable in
five bits, i.e. [0,31].



>
> And since it is perfectly legal to have a "MyEnum" variable with a value
> of INT_MAX, the "enum_max" of an enumerated type is simply the maximum
> value of the underlying type.
>

... for an enumeration type with a fixed underlying type.


>
>
> I am sure a lot of people (including me) would like strong enumeration
> types that may only (by defined behaviour) hold the values given in the
> enumeration, and then it would sometimes be very useful to have a
> minimum and maximum value. But we don't have that at the moment - it
> may have to wait for reflection and/or metaclasses. Until then, I don't
> think a standardised enum_min and enum_max function could make sense.
>
> (It might be feasible to have these as compiler-specific extensions.
> After all, many C++ compilers can give helpful warnings about assigning
> arbitrary values to enumerated types, so they have the required metadata
> on hand. But I can't see how that would be standardised, and such
> extensions would be outside of the scope of this list.)
>
>
> > At the very least, I'd use this cast always within a template or macro
> > called to_enum<type>(value) or to_enum(type, value). But probably in a
> > project-defined one, and not a standard one.
> >
> > Cheers,
> > Alex
> >
> >
> > So you need to give some actual rationale for your proposal.
>
>
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>