Re: [boost] Is there interest in a library for string-convertible enums?

Subject: Re: [boost] Is there interest in a library for string-convertible enums?
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2014-11-04 22:13:09

On 29/10/2014 23:04, Felix Uhl wrote:
> Gavin Lambert wrote:
>> - can round-trip (enum -> string -> enum) values that are not members
>> of the enumeration; of course (string -> enum -> string) is not
>> feasible for non-members.
>
> What would a conversion from an enum that is not a member to a string
> look like? Should it just be converted to the string representation of
> the underlying type like “7”? Or something like “MyEnum::7”?

Dealer's choice.  IIRC my implementation rendered it to "#7".

> Or would the string representation solve a term with bitwise OR like
>
> so: “one|two|four”? The latter would be very interesting for bitwise flag enums.

Only if it's explicitly marked in some way as a bitwise enum.  Otherwise 
it would be more confusing than helpful.

>> - can specify a custom string value that the enum value generates (not
>> just the BOOST_PP_STRINGIZE).
>
> Yeah I will implement that. Not sure why one would want it, it does nothing
> but induce confusion in my eyes, but I’m not the one to tell you what to do.

There are a couple of different reasons why this has been useful:

1. Language interop.  When used for data interchange serialisation, 
different languages may have different naming conventions.  eg. C# might 
have an enum value called "Rectangle" but C++ would have it called 
"SHPT_RECT".

2. Abbreviation, and the reverse (for diagnostics or other 
display-to-user cases).  Sometimes the code has a long expressive name 
but it needs to be displayed somewhere where a shorter name is needed 
due to space constraints.  Other times, the code has a cryptic name like 
the above but it needs to be displayed somewhere in a more 
human-readable form.

>> - enum to string and back for "bitwise flag" style enums (eg. CSV names).
>
> Not sure what you mean by that, because the regular string conversions work
> for those just as fine. Do you mean what I wrote above with the OR
> connected values in a string representation?

Yes, although I was thinking of comma-separated, as C# bitwise enums do it.

>> - can specify multiple string values that map to the same enum value.
>
> Hm. I’m not sure if I’d want that, or how that could even be implemented.
>
> If somebody wanted non-casesensitive behaviour, it would be better to use
> a std::string with custom char_traits, and that’s something I’ll definitely
> offer.

I wasn't thinking of case sensitivity, but again of interop and 
serialisation.  Maybe in an older version of an application something 
was saved as "Rect" but in the current version it's saved as 
"Rectangle".  It would be nice if it could load both versions 
successfully, but they map to the same value.  Similarly, maybe a C# 
client could send one string and a C++ client send another.  Obviously 
in the enum -> string direction only one of these would "win" (selected 
by the developer somehow, eg. the first listed).

Another (more complex) case evolves with bitwise enums; perhaps instead 
of rendering "Foo|Bar|Baz" it should render "All", or instead of 
rendering "Frob1|Frob2|Frob3|Foo2" it should render "AllFrob|Foo2", 
where someone has defined named aliases for certain combinations.

On 30/10/2014 07:45, Rob Stewart wrote:
> You should not add features because someone on this list asked for
> them. If you're not convinced of the utility of something, push back
> to understand the request better.

Of course.  I was just offering suggestions based on things that have 
come up when using my own version, since they were being solicited. 
It's naturally up to the library author to decide which of these make 
sense for their particular vision of the library or its intended usage.