Maybe call it std::enum_max_declared and std::enum_min_declared ?

On Mon, Jul 10, 2023 at 8:33 AM Jonathan Wakely via Std-Proposals <
std-proposals_at_[hidden]> wrote:

>
>
> 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
>>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>