Merging scanned enums that share common members

[sotteson1]

We're looking at improving parameters and fields to use more enums that we scan from the constants in the docs. However, we've noticed that sometimes we find APIs that share a list of values, but don't share the complete list. One example:

BroadcastSystemMessage
Its "flags" parameter accepts 9 different values that start with BSF_

BroadcastSystemMessageExA
Its "flags" parameter accepts the same 9 values that start with BSF_, but also two more

The question is what do we do in this case? We could either make two different enums, one for the 9 values and one for the 11 values, or combine them into one set, even though two of its values are invalid for BroadcastSystemMessage. I'm leaning towards combining them into a single enum, but whatever we decide we want to have a consistent strategy that we stick with.

[AArnott]

I support merging them. Callers should always reference the documentation to learn what flags are allowed and under what circumstances.

[mikebattista]

Especially in this case where one function is just an -Ex of the other, I support a single shared enum. Is this the common scenario you've run into here?

[AArnott]

Is this the common scenario you've run into here?

Which scenario are you referring to? Sharing enums without exact matches? @sotteson1 would have to answer that as he did the human analysis to find the near-duplicates.

[mikebattista]

The scenario of non-Ex and -Ex methods mostly sharing the same values, rather than two methods that mostly share values but are completely different.

[sotteson1]

The algorithm I'm using does attempt to merge them. We might find examples where the result isn't what we want, in which case we can manually define them however we want.