Re: [boost] [Better Enums] More complete release - feedback requested

Subject: Re: [boost] [Better Enums] More complete release - feedback requested
From: Anton Bachin (antonbachin_at_[hidden])
Date: 2015-06-10 13:39:27

Hi,

Thanks for the comments.

> A. get rid of the leading _ un function names.

The reason I chose to add the _ is that the function names occupy the same
namespace (I don’t mean the C++ keyword) as the constant names, i.e. if I had a
function such as “Channel::valid()" it would conflict with a potential
user-declared constant Channel::valid. I’m open to better suggestions than using
underscores, though.

I had an alternative implementation (which is internally almost the same), in
which the ENUM macro generated type traits over an enum (or enum class, in
C++11), instead of wrapping an enum in an object, as now. That is, instead of
notionally generating

struct Channel {
    enum _enumerated { … };
    // Methods
};

it generated

enum class Channel { … };
template <>
struct traits<Channel> {
    // Methods
};

In this implementation, the methods were in their own namespace, so there was no
need to use underscores. Also, there was no need to have operator+, and the
interface, in general, was very uniform. However, the usage was usually much
more verbose:

Channel::_from_string(“Red”);
vs.
better_enums::traits<Channel>::from_string(“Red”);

I could get some degree of type inference to happen by wrapping the traits
functions in freestanding template functions, but it was still too verbose
(IMO), and also threw away the advantage of a uniform and easy-to-remember
interface.

There might be a way to make this work nicely - I am open to suggestions. It
might actually be possible to have decent syntax with traits, using some helper
types to get type inference, along the lines suggested by Tony Van Eerd in an
earlier message. I will look into that.

However, I am working on a feature that allows the underlying type of a Better
Enum to be any literal type that provides conversions to/from an integral type.
It’s essentially an adapter between anything and the switch statement. That
feature would not be possible with a traits approach in the form I outlined
above.

> B. make size a constexpr function

What would be the advantage to this? Uniformity of interface? Is there any
disadvantage from this change? I generally want to move in the direction of
making more things available to C++03 metaprogramming, so I am worried about
making constants into functions.

> C. add to_integral() (or is that done by a static cast?)

Do you mean this?

http://aantron.github.io/better-enums/ApiReference.html#_to_integral

I didn’t put it into the example in the README/documentation front page because
it’s not much of a feature, and I’d rather save space. Do let me know if you
think that’s misleading on my part.

> Somthing to consider: One reaching for an enum, one very often needs a small statically sized, immutable bidirectional map. That is, the mapped strings needs not be the name of the enum constant. Key-value pair iteration may be useful and

Noted, thanks. I think this could be covered by a solution that would also take
care of a use case Gavin Lambert described yesterday. I will look into it.

And, thanks for the links. I did see the first one, but not the second.

Best,
Anton