This is exactly what I was talking about. This is just the default behavior
and formatting *you* think should be the default. There are many different
views on this and a library solution like the one presented in P1240 does not
limit you to implement the behavior you want. A built-in solution would limit
you tho.

However you are correct about the UB thing in my example. You run into the
same problem anyways if you make the enum fixed:

enum Color : int {
  red /* = 0 */,
  green /* = 1 */,
  blue /* = 2 */
};

Color col = 3;
std::string enum_str = enumerator_name_by_value(col);


Sebastian

On Sonntag, 10. November 2019 03:19:07 UTC connor horman via Std-Proposals
wrote:
> Isn’t this particular example UB, since Color doesn’t have a fixed
> underlying type, or does it have to be out of the bit-range for that.
> Either way, couldn’t an undefined enumerator just be <name of
> class>{<value>};
>
> On Sat, Nov 9, 2019 at 7:50 PM Sebastian Büttner via Std-Proposals <
>
> std-proposals_at_[hidden]> wrote:
> > The second one I belief would work but it will give you the name of the
> > variable, so "value" instead the one of the corresponding enumerator.
> >
> > Unfortunately it is not easily possible to provide a universal solution
> > for
> > enumerator_name_by_value(value) because any value that fits into the
> > underlying
> > type of an enum type can be converted to that enum. Thus this is valid:
> >
> > enum Color {
> >
> > red /* = 0 */,
> > green /* = 1 */,
> > blue /* = 2 */
> >
> > };
> >
> > Color col = 3;
> > std::string enum_str = enumerator_name_by_value(col);
> >
> > This is valid code (correct me if I am wrong please). As of
> > http://eel.is/c+
> > +draft/dcl.init#list-3.8 <http://eel.is/c++draft/dcl.init#list-3.8>
> > direct-list-initialization is performed not checking
> > whether the value we actually assign has an corresponding enumerator or
> > not.
> >
> > What should enumerator_name_by_value() return? An empty string? Some
> > placeholder like name like "Undefined"? I think this is application
> > dependend
> > and thus cannot be done in the language it self. A viable library solution
> > to
> > this problem is the one you saw in the Reflection paper.
> >
> > At least for now I cannot (sadly) think of a universal solution to this
> > problem that is nicer to spell than the existing example... However as you
> > only would require once such function for a given default behavior and
> > formatting taste it would be at least feasible to handle all of your
> > enumerations by one library function. Which would be a great win imo :-).
> >
> > Sebastian
> >
> > On Samstag, 9. November 2019 23:13:40 UTC Jonny Grant wrote:
> > > Many thanks Sebastian
> > >
> > > Yes, that example looks useful!
> > >
> > > Would be nice to be able to simply call directly:
> > > std::string enum_str = std::meta::name_of(value);
> > >
> > > or at least:
> > > std::string enum_str = std::meta::name_of(reflexpr(value));
> > >
> > > or even nicer:
> > > std::string enum_str = value.str();
> > >
> > >
> > > Let's see how things end up.
> > >
> > > Thank you
> > > Jonny
> > >
> > > On 09/11/2019 20:57, Sebastian Büttner wrote:
> > > > I aggree on both your statements.
> > > >
> > > > However I still think that the problem is just one of many in that
> >
> > domain.
> >
> > > > With reflection at hand we will be able to solve this and even way
> >
> > more
> >
> > > > like enumerating class members and so on.
> > > >
> > > > WG21 still has no common direction on this, however significant work
> >
> > has
> >
> > > > already been done. It is still a long way to go tho. There is at least
> >
> > one
> >
> > > > major proposal on this in flight (with some serious opposition to it).
> > > >
> > > > You might want to have a look at P1240 (Scalable Reflection in C++,
> > > > http://
> > > > www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1240r1.pdf).
> > > >
> > > > The first example on page 2 is already what you are looking for (kinda
> >
> > at
> >
> > > > least).
> > > >
> > > > Sebastian
> > > >
> > > > On Samstag, 9. November 2019 19:40:41 UTC Jonny Grant wrote:
> > > >> Seems a shame if we need to write a python script to generate the
> > > >> to_string_str for each enum.
> > > >>
> > > >>
> > > >>
> > > >> Don't you just hate it when you get a debug log that shows :-
> >
> > --
> > Std-Proposals mailing list
> > Std-Proposals_at_[hidden]
> > https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals