I personally don't think it is a lot of trouble to set those values manually (although it would be a little nicer if we could use something like "1 << 2" there).

Having another attribute is one more thing to learn/support and also less explicit. WDYT?

My main concern is having large numbers if the number of enum values is particularly large. This makes it harder to confirm that the value is correct and could lead to mistakes.

Using bit shifts would definitely help as you could tell at a glance whether the value sets the correct bit.

That documentation page is out of date. Mojom enums don't work well for bitfields. For C++, they generate scoped enums which don't implicitly cast from or to the underlying storage type so bitwise operations require casts.

Instead, use constants for the values and an int of matching size as the bitfield type. See https://cs.chromium.org/chromium/src/ui/events/mojo/event_constants.mojom.

I had a discussion with mbrunson@ about this off-thread a few days ago, so I'm just going to persist what I remember from it here.

My comment was roughly the same as sammc@'s: C++ enum classes are not compatible with the treatment of enums as bitfields. This is trivial to see because the disjunction of any two valid enum values produces an invalid enum value.

There are two alternatives:

1. Integer constants and integer IPC fields. Pro: simple, Con: not typesafe, not automagically validated

2. Structs of bools. Pro: typesafe and obviously validated, Con: more verbose, maybe not idiomatic historically?

mbrunson@ informed me that #2 was the original approach used in his case, but that he was advised to change it. I would like to advocate that we consider this option more carefully.

Approach #2 seems OK to me; it's not super efficient in terms of packing, but it's not that bad either. The struct traits can map from bool fields back to bitsets too if it wants.

bools are packed tightly in mojom structs, if that's what you're referring
to. The extra indirection is unfortunate if we don't inline the struct, but
we should be able to trivially improve the rule which dictates inline vs
non-inline.

In that case, even better =)

RE #6: when you said "inline", do you mean (1) using InlinedStructPtr to avoid heap allocation; or (2) changing mojo wire format so that we don't have indirection in the encoded message?

(1) could be easily done; (2) however will affect versioning and therefore we need to be careful about this.

Oh I just meant the first one. Changing the wire format doesn't seem
necessary.

Per discussion, using enums for bitfields is strongly discouraged.