Re: [boost] interest in a flag library

Subject: Re: [boost] interest in a flag library
From: Joseph Van Riper (fleeb.fantastique_at_[hidden])
Date: 2018-10-29 09:44:50

On Sun, Oct 28, 2018 at 7:01 PM Arvid Norberg via Boost <
boost_at_[hidden]> wrote:

> On Thu, Oct 25, 2018 at 11:28 PM Masse Nicolas via Boost <
> boost_at_[hidden]> wrote:
>
> > Hi all,
> >
> > [...]
> >
> > enum struct option : uint
> > {
> >     none = 0,
> >     first = 1,
> >     second = 2,
> >     third = 4,
> >     forth = 8
> > };
> >
> > static constexpr flags<option> var1 = option::first;
> > static constexpr flags<option> var2 = option::second | option::third;
> > static constexpr auto var3 = var1 | var2; /* type will be resolved into
> > flags<option> */
> > static constexpr auto var4 = option::first | option::second |
> > option::third; /* works too */
> >
>
> I think a better approach is to fully define the flag type as a class
> (without the enum).
>

I think it valuable to have the enum approach for a relatively simple
handling of third-party libraries, etc. that know nothing of this library,
as it would involve little to no effort to use them within this library.
Perhaps one might explore both approaches?

This enum approach eases adoption by allowing someone to use this class
with existing enumerations, such as std::ios::flags.  Although, I am
concerned that it may lack the handling of enums not cast as a class or
struct.  How would it identify the appropriate type to which to resolve in
such situations?

- Trey