DDSXTY12 — The current assignability rules are complex and too restrictive

The existing type compatibility rules create situations where DataWriters are not able to communicate with DataReaders because of type differences that could be easily accommodated by the type system.

The assignability rules for strings are sequences are following the meta-rule: “If type T1 can have an object O1 that is not assignable to type T2, then type T1 is considered un-assignable to T2”. For example according to Table 13 string<256> is unnasignable to string<32> and sequence<long, 256> is unnasignable to sequence<long, 32>.

Feedback from users indicates that this is undesirable. For example a type may have been designed containing a string<256> but never used to send strings longer than 30 characters. Then in a later version the type is modified to string<32> in order to reduce the max length to the actual size needed to conserve memory resources. This would make the new version of the type incompatible with deployed systems even if all the strings ever sent fit in the string<32> type.

Type assignability rules are also complex because they are defined as an asymmetric relationship: T1 is-assignable-to T2. rather than a symmetric one. Another complexity comes from the need to define of "strong assignability" which captures the case where T1 is-assignable-to T2 and the end of the T1 object can be determined by T2. This is needed when the T1 appears nested inside another type or in a sequence.

The main reason to define this asymmetric rule was caused by the previous point of having types like string<10> assignable to string<100> but not the other way around. If we change these assignability rules for strings/sequences then the need for the asymmetric is-assignable-to relationship goes away and can be replaced by a symmetric "is-compatible-with"

The "strong assignability" is an artifact of the way extensible types are serialized. If they were serialized wrapped with a "length" around them as with the APPEND extensibility we would not need this concept.

Increase flexibility of assignability rules

Introduce new rules to increase the set of types that are assignable and avoid discarding data as soon as an object that does not "fit" into a target type.

• Change compatibility of sequences and strings so that the types are compatible regardless of the length. Object initialization requires SOURCE.length <= TARGET_TYPE.length if not the object cannot initialize an object of the TARGET type. This affects Table 13.

• Introduce a @TryConstruct annotation that can be used to indicate that an unassignable member does not cause the complete object to be dropped. Instead, the member is set to its default value.

• Allow the use of @DefaultLiteral annotation on enum to allow selecting a default value for an enumeration other than the first or one with smallest member ID.

• Change compatibility of unions and structures to take into consideration the @TryConstruct annotation.

• Introduce some clarifying examples

More details can be found in the attached document: TypeCompatibilityProposal_v3.docx