RFC: BitMask helper ADT

[Justin Lebar via llvm-commits]

(Here's the patch, for others who might not have context in their mail
client: http://lists.llvm.org/pipermail/llvm-commits/attachments/20150623/073434b6/attachment.obj)

The idea that Chandler and Richard Smith came up with was to enable
bitwise operations directly on an enum type, conditioned on the enum
opting in via a traits class.

If this works, it would obviate the need for a wrapper, which would be
very nice, I think.

I'm going to try it out tomorrow.  I definitely would like to get
*some* sort of strong typing in place, because it's too easy to switch
the order of the args after my refactoring of SelectionDAG::getLoad
and friends.

On Mon, Jul 11, 2016 at 6:58 PM, Saleem Abdulrasool
<compnerd at compnerd.org> wrote:
> On Tue, Jun 23, 2015 at 4:12 PM, Saleem Abdulrasool <compnerd at compnerd.org>
> wrote:
>>
>> Hello,
>>
>> While looking at something unrelated (yay yak-shaving!) ... it came up
>> that it may be convenient to actually re-use enumerations as bit masks in
>> certain cases (assuming that the values are appropriately disjoint).
>>
>> The thing is that enum classes are becoming more prevalent, and they are
>> not simply usable in logical operations without casting.  The "solution" to
>> this is replicate the enumeration.  The helper helps avoid the extensive
>> casting by wrapping up the underlying type into a helper that simply
>> provides the overloads for the normal (logical) operations.  It would also
>> allow the re-use of the enumeration rather than duplicate the values.
>>
>> The implementation presented here should work with MSVC 2013, clang and
>> GCC.  It is more of a proof of concept, that this is possible.  This thread
>> is meant to raise the question of: is this a good idea?  Do we want to just
>> use unsigned for bit masks instead?
>>
>> (A thank you goes out to Aaron for a discussion on this idea and help with
>> some of the nastier pieces of the metaprogramming here).
>>
>> One point that I know will most definitely be brought up: the implicit
>> boolean conversion.  Yes, its implicit, and yes that was an explicit choice.
>> The problem is that the use of logical operators as conditions is pretty
>> extensive, so this conversion operator tends to be involved quite often, and
>> would be needed to keep the idiomatic use in place.
>
>
> Seems that this idea came up again.  What does this add to my necromancy
> skills?
>
>>
>> --
>> Saleem Abdulrasool
>> compnerd (at) compnerd (dot) org
>
>
> --
> Saleem Abdulrasool
> compnerd (at) compnerd (dot) org