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
>