std::enum

[Halfdan Ingvarsson]

I'd like to propose a simple, but very useful utility class for the standard library: std::enum.  

All it does is take a template parameter, which would be an enum type.

It would then allow you to access the individual elements of that enum, in order of declaration, using a nearly identical interface as std::array<> (i.e either through enumerators, or operator[]).

E.g: 

#include <iostream>
#include <enum>
#include <algorithm>


enum Color { Red = 1, Green = 2, Blue = 23 };


int main()
{
   auto e = std::enum<Color>();
   for( auto v: e)
   {
     std::cout << "Elem: " << v << "\n";
   }
   std::cout << "Size: " << e.size() << "\n";
   std::cout << "Largest: " << std::max_element(e.begin(), e.end()) << "\n";
   return 0;
}

Output:

Elem: 1
Elem: 2
Elem: 23
Size: 3
Largest: 23

I assume that this would have to take some form of a help from the compiler, similar to how std::underlying_type is implemented. However, this would obviate the current set of hacks that either require macros, special class constructions, or other inconvenient forms.

[Thiago Macieira]

On Tuesday, 20 June 2017 20:34:28 PDT Halfdan Ingvarsson wrote:
> I'd like to propose a simple, but very useful utility class for the
> standard library: std::enum.

You need to find a different name. We can't have a class whose name is a
reserved keyword.

> All it does is take a template parameter, which would be an enum type.
>
> It would then allow you to access the individual elements of that enum, in
> order of declaration, using a nearly identical interface as std::array<>
> (i.e either through enumerators, or operator[]).

You're asking for enum reflection. There are many proposals about that, both
restricted to enums as well as generic (reflection for everything). The
restricted proposals haven't gained much traction, so everything now depends
on the full reflection proposals being accepted.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center

[wei zhang]

I won't think it can be done with only add lib.

For the samething I would suggest enum class will have a static const variable array.

so that you could write

const auto & e =Color.array

在 2017年6月21日星期三 UTC+8上午11:34:28，Halfdan Ingvarsson写道：

[Halfdan Ingvarsson]

On Wednesday, June 21, 2017 at 12:06:54 AM UTC-4, Thiago Macieira wrote:

On Tuesday, 20 June 2017 20:34:28 PDT Halfdan Ingvarsson wrote:
> I'd like to propose a simple, but very useful utility class for the
> standard library: std::enum.

You need to find a different name. We can't have a class whose name is a
reserved keyword.

Er. Yes. std::enum_array. It got lost in the wash.

 

You're asking for enum reflection. There are many proposals about that, both
restricted to enums as well as generic (reflection for everything). The
restricted proposals haven't gained much traction, so everything now depends
on the full reflection proposals being accepted.

Indeed. 

So far, the only proposal I've seen where I can easily enumerate an enum in a for-each, is the one from Sutton and Sutter (P0590R0). The rest are a form of a <foo>::get<I>() template, where, if the proposal doesn't include it, one would be forced to write some variadic template magic to cover that aspect.

However, the front-runner reflection proposals all rely on the existence of concepts in the standard, which makes me think that we're nowhere near anything resembling reflection for a long time indeed.

[Halfdan Ingvarsson]

On Wednesday, June 21, 2017 at 12:12:44 AM UTC-4, wei zhang wrote:

I won't think it can be done with only add lib.

For the samething I would suggest enum class will have a static const variable array.

so that you could write

const auto & e =Color.array

That's why I mentioned that it would have to have some help from the compiler.

For example, std::underlying_type, on clang and gcc, rely on an intrinsic called __underlying_type(), which takes a type argument. In this case there needs to be something like __enum_members(), which would be substituted by an braced init list that contains the enum members at compile time.

[Thiago Macieira]

On Wednesday, 21 June 2017 05:34:29 PDT Halfdan Ingvarsson wrote:
> However, the front-runner reflection proposals all rely on the existence of
> concepts in the standard, which makes me think that we're nowhere near
> anything resembling reflection for a long time indeed.

No, we're not. But since the proposals for restricted reflection haven't gained
much traction, then it seems like we'll have to wait for the generic solution.

[Patrice Roy]

Since the Issaquah meeting, reflection seems to be getting more and more realistic. I think there's legitimate space for hope in the near (non-17) future...

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-pr...@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2384155.IuquL1aeVr%40tjmaciei-mobl1.

[Mingxin Wang]

On Wednesday, June 21, 2017 at 11:34:28 AM UTC+8, Halfdan Ingvarsson wrote:

I'd like to propose a simple, but very useful utility class for the standard library: std::enum.  

All it does is take a template parameter, which would be an enum type.

It would then allow you to access the individual elements of that enum, in order of declaration, using a nearly identical interface as std::array<> (i.e either through enumerators, or operator[]).

Because this depends on new language features, I think the motivation in converting a "enum" to an array is not explicit enough.

As a user to the enum, I usually care "the mapping between names and values" more than "the order of declaration". Would it be more reasonable to convert an enum to an initializer list? For example:

enum E { ZERO = 0, ONE = 1, TWO = 2 };

std::map<std::string, int> a = MAKE_MAP(E); // MALE_MAP(E) is equivalent to {{"ZERO", 0}, {"ONE", 1}, {"TWO", 2}}

Still, I think there should be more motivation. As I can imagine, this feature is helpful in debugging and exception information generation.

Mingxin Wang