Re: [PATCH] Type-safe wrapper for enum flags

[Patrick Palka <patrick@parcs.ath.cx>]

On Tue, Nov 3, 2015 at 6:17 AM, Pedro Alves <palves@redhat.com> wrote:
> On 11/01/2015 03:19 PM, Patrick Palka wrote:
>
>>> +
>>> +public:
>>> +  /* Allow default construction, just like raw enums.  */
>>> +  enum_flags ()
>>> +  {}
>>
>> Why not zero-initialize enum_value here? Given that enum_flags
>> represents a bitwise OR of enum_type, it seems reasonable that its
>> default value would be zero rather than uninitialzied.
>
> My reasoning was to make this look as much as a raw enum as possible.
> If one is zero initialized and other isn't, then I'm going to be
> staring at (client) code wondering whether to initialize or not.
> Making it be like raw enums, the rule is simple.
>
> But, in any case, client code will still need to explicitly initialize
> in C mode, as then the flags enum is just a typedef.  Thus seems best
> not to rely on default initialization as long as we support C mode.

That makes sense.

>
>> What are global operator^ and operator& omitted?
>
> Simply because nothing in the code base trips on the
> need for them.  They'd be needed for things like:
>
>  flags f1 = ((enum flag_values) some_input_int) & FLAG_VAL1;
>  flags f2 = ((enum flag_values) some_input_int) ^ FLAG_VAL2;
>
> I'll add them.
>
> Thanks for the review!

FWIW the latest patch looks good to me.

BTW, I think GCC could make use of this enum_flags abstraction. When
GCC moved to C++ it seems to have went the type-unsafe route regarding
enum compatibility, converting  "enum foo { ... };" to "enum foo_flags
{ ... }; typedef int foo;" which is a pretty inferior solution. Do you
plan on incorporating this abstraction into GCC too? If not, I can
help to do it.