That is not fully true.   Create a class type with private constructor.   Create the constants as static member variables inside the class.   You can keep a copy constructor public.   -----Ursprüngliche Nachricht----- Von:Ryan Klaus via Std-Proposals <std-proposals_at_[hidden]> Gesendet:Fr 14.03.2025 21:32 Betreff:Re: [std-proposals] enum with non-integral types An:std-proposals_at_[hidden]; CC:Ryan Klaus <rfklaus117_at_[hidden]>; Why use enumerations over named constants ever? Because new (valid) enumeration values can't be added after the definition.  With named constants, a user can just create a new constant of the same type anywhere they like and pass it to any function accepting that type. Nothing explicitly prevents this or tells the user they shouldn't do this outside of documentation.  With an enumeration, the writer of the enum gets to define the exact list of constants that can be passed to a function accepting that enum type, barring explicit casts of course. There's no way for a user to expand the list of valid constants without doing something hacky like going to the header and modifying the enumeration directly. On Fri, Mar 14, 2025, 2:37 PM Tiago Freire via Std-Proposals <std-proposals_at_[hidden] <mailto:std-proposals_at_[hidden]> > wrote: What would be the benefit of this over let’s say... regular named constants?     -------------------------------- From: Std-Proposals <std-proposals-bounces_at_[hidden] <mailto:std-proposals-bounces_at_[hidden]> > on behalf of Filip via Std-Proposals <std-proposals_at_[hidden] <mailto:std-proposals_at_[hidden]> > Sent: Friday, March 14, 2025 5:34:55 PM To: std-proposals_at_[hidden] <mailto:std-proposals_at_[hidden]> <std-proposals_at_[hidden] <mailto:std-proposals_at_[hidden]> > Cc: Filip <fph2137_at_[hidden] <mailto:fph2137_at_[hidden]> > Subject: [std-proposals] enum with non-integral types Hi everyone, in other thread “lambdas in enums” I have talked about enums having different underlying type. I’m starting a new thread to organise the features. ------ I would like to use enums with different underlying type. I have considered using inheritance style list: ``` enum struct Foo : int, float {         A {3, 0.f},         B { …, 1.f} // `…` to indicate that following element should follow increment from previous value }; ``` However it does pose several problems so other possibility is to use only one type and an initializer list. Type used should have: + constexpr constructor, + constexpr default constructor + constexpr operator ++ const [if the values are not provided, could be explicitly deleted to force user to implement all values] ``` enum struct Foo : someType {         A{ ~initializer list for `someType`~ },         B,                // by default it calls ++ operator on previous enum value         C = default, // this could be an explicit way to show that enum generation should increment the value         D {}             // default initialisation of someType }; ``` The second option of new syntax allows us to easily access different values that we want to store. ``` Foo::A // is equivalent to static constexpr someType ``` Additional concerns: + sizeof(Foo) should be consistent with current enum sizeof functionality and return sizeof(someType). + initializer list is probably the only way to have multiple values per symbol + different enum values are not compared to each other when created not now so should not be with custom objects. + template enum struct should be possible in the future: ``` template <typename T, typename U> enum struct Bar : std::pair<T, U>{}; ``` -- Std-Proposals mailing list Std-Proposals_at_[hidden] <mailto:Std-Proposals_at_[hidden]> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals   -- Std-Proposals mailing list Std-Proposals_at_[hidden] <mailto: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