Legacy Issue Number: 18297
Source: ADLINK Advanced Technology Office ( Erik Hendriks)
if strongly assignable according to section 7.2.4 means that both types should be mutable, then why is the union in Table 15 (section 22.214.171.124, fifth bullet in 2nd column) talking about strong assignability for a T1 that is final or extensible?
- Probably the definition for strongly typed is flawed, and should be about NON-mutable types.
Generally speaking, the overall wording of the subject regarding strong assignability could is causing more confusion than it is clearing things up, and could use some big improvement.
Lots of usecases regarding this subject are underspecified, for example:
- If a type T1 is assignable from a type T2, and T1 has a non-optional member that is not represented in T2, it takes the default (non-configurable) default.
How can I see the difference between a T1 with a member, that happens to be the default, and a T1 without that member?
Since 0 is a very common value, it does not seems like a good candidate for default in this case.
Reported: DDS-XTypes 1.1 — Wed, 12 Dec 2012 05:00 GMT
Disposition: Resolved — DDS-XTypes 1.2
Clarified definition of strongly assignable
Updated section 7.2.4 with clearer definition of strongly assignable. Also updated union_type in Table 15 section 126.96.36.199 Aggregation Types.
Updated: Thu, 22 Jun 2017 16:42 GMT