DDSXTY13 — Compatibility of Enum should be allowed even if there is just one common literal

The compatibility rule for ENUM_TYPE Table 18 'Definition of the is-assignable-from relationship for bitmask and enumerated types' states:

• If extensibility is final the set of literals should be identical. Otherwise the two types should have at least one other literal (in addition to the default one) in common.

This will break types that were compatible in xtypes v1. Namely enumerated types that just had one literal in common.

Defining enumerations with a single literal which is then expanded is a common patten in a surprising number of applications. So this change is quite disruptive.

The proposal is to not require the minimum of two literals in common. In other words change the quoted paragraph to:

• If extensibility is final the set of literals should be identical.

In addition some people dislike the fact that we make enums that have different default values incompatible. This will make two enums like the ones shown below incompatible. There is a strong opinion that this will break a lot of existing systems:

enum Enum1 {
   @value(1) RED,
   @value(2) BLUE
};

enum Enum2 {
   @value(2) BLUE,
   @value(1) RED
};

enum Enum3 {
   @value(2) BLUE,
   @value(1) RED,
   @value(0) ORANGE
};

So the proposal is to also remove the requirement:

• The default literal has the same value.

Lastly there question/request to have the TypeEnforcementPolicy attribute ignore_member_names apply to Enum as well... Alternatively it could be a different policy attribute, e.g. ignore_enum_literal_names.
We have several customers that have this requirement.

Modify compatibility for enum types and non-final extensibility

Apply the changes suggested in the issue description.