Bitwise annotation for Enums, and Flags property for declarations

[ThunderFrame]

RD could expose several inspections for bitwise enums, if it only knew that the enums should be regarded as being bitwise.

We could make a best-efforts guess about whether a user-defined enum is bitwise, but that could yield false-positives with an enum like this:

Enum Foo
  Am
  I
  Bitwise
End Enum

If we could add an annotation (and I suggest we use the .NET-inspired @Flags annotation, then RD would know the intent of the Enum:

'@Flags
Enum Foo
  Must
  Be
  Bitwise
End Enum

Then RD could inspect for enums that implicitly/explicitly assign values that aren't bitwise, although there might need to be some consideration for enum members that are assigned using bitwise expressions (for example, where a user declares a bitwise combination member, for convenience):

Enum UserResponse
  'Bitwise members
  Cancel = 1
  Ok = 2
  Abort = 4
  Retry = 8
  'Convenience members
  OkOrCancel = OK Or Cancel
  AbortOrRetry = Abort Or Retry
End Enum

When collecting COM enums defined in type-libraries, we could manually define the bitwise nature of known bitwise enums:

Eg: VbFileAttribute is a pure bitwise enum

Enum VbFileAttribute
  vbNormal = 0
  vbReadOnly = 1
  vbHidden = 2
  vbSystem = 4
  vbVolume = 8
  vbDirectory =16
  vbAlias = 64
  vbArchive =32
End Enum

Whereas VbStrConv seems like it might be bitwise (VB.NET documentation marks it with a Flags attribute), but with an explicitly non-bitwise member:

'declared in alphabetical order - the same as the VB.Net declaration order...
Enum VbStrConv
  Hiragana = 32;
  Katakana = 16;
  LinguisticCasing = 1024;
  Lowercase = 2;
  Narrow = 8;
  None = 0;
  ProperCase = 3; 'Explicitly non-bitwise, but happens to be an invalid combination of Uppercase Or Lowercase
  SimplifiedChinese = 256;
  TraditionalChinese = 512;
  Uppercase = 1;
  Wide = 4;
End Enum

[bclothier]

Considering the 2nd part -- how would one handle an enum like vbMsgBoxStyle? It's actually a mixture of bitmask (flag) and .... non-bitmask. (the constants for button styles from 0 to 5 aren't really bitmask.

[ThunderFrame]

@bclothier Well, Microsoft marks it with a Flags attribute, so presumably the 0-5 values are designed to be mutually exclusive, much like the VbStrConv.ProperCase example I gave.

When it's a COM-defined enum, that RD sets as being Flags, RD won't be offering any inspections on the Enum itself, but rather on usages of the enum that, for example, use + instead of Or.

When it's a user-defined Enum that's annotated as Flags, and there are non-bitwise members, IMO, RD should inspect for those non-bitwise members, but also allow individual, non-bitwise members to be ignored (by annotating individual members something like '@IgnoreFlagNotBitwise).

[bclothier]

Just to add one more possible annotation for this - '@Sequence which would indicate that the enum should not have a constant defined for any of its member as the listing of members will be used to govern the sorting of the members. In this case, we typically want a contiguous and monotonically increasing values for each member. This is best done by simply not specifying any constant values.