!standard 4.9.1(4/2) 08-01-28 AI05-0086-1/01 !class binding interpretation 08-01-28 !status work item 08-01-28 !status received 08-01-17 !priority Low !difficulty Medium !qualifier Omission !subject Statically compatible needs to take null exclusions into account !summary (See Subject.) !question The definition of "statically compatible" (4.9.1(4)) ignores null exclusions. This doesn't seem right. !recommendation (See Subject.) !wording Change 4.9.1(4) as follows: A constraint is statically compatible with a scalar subtype if it statically matches the constraint of the subtype, or if both are static and the constraint is compatible with the subtype. A constraint is statically compatible with an access or composite subtype if it statically matches the constraint of the subtype, or if the subtype is unconstrained. One subtype is statically compatible with a second subtype if the constraint of the first is statically compatible with the second subtype{, and in the case of an access type, if the second subtype excludes null, then so does the first}. !discussion This appears to be an oversight. With the current rules, the following example passes the test of 3.7(15): declare type Ref is access Integer; type R1 (D1 : not null Ref) is null record; type R2 (D2 : Ref) is new R1 (D1 => D2); begin null; end; But this is bad for all of the reasons given in AARM 3.7(15.a). !corrigendum 4.9.1(4) @drepl A constraint is @i with a scalar subtype if it statically matches the constraint of the subtype, or if both are static and the constraint is compatible with the subtype. A constraint is @i with an access or composite subtype if it statically matches the constraint of the subtype, or if the subtype is unconstrained. One subtype is statically compatible with a second subtype if the constraint of the first is @i with the second subtype, and in the case of an access type. @dby A constraint is @i with a scalar subtype if it statically matches the constraint of the subtype, or if both are static and the constraint is compatible with the subtype. A constraint is @i with an access or composite subtype if it statically matches the constraint of the subtype, or if the subtype is unconstrained. One subtype is statically compatible with a second subtype if the constraint of the first is @i with the second subtype, and in the case of an access type, if the second subtype excludes null, then so does the first. !ACATS Test A B-Test needs to check that null exclusions are checked in these cases. !appendix From: Stephen W. Baird Sent: Thursday, January 17, 2008 1:17 PM The definition of "statically compatible" (4.9.1(4)) ignores null exclusions. This means that the following example passes the test of 3.7(15): declare type Ref is access Integer; type R1 (D1 : not null Ref) is null record; type R2 (D2 : Ref) is new R1 (D1 => D2); begin null; end; I think that this example should be rejected for the reasons given in AARM 3.7(15.a). The version of AI05-0057 I posted recently adds new uses of "statically compatible" for deferred constants and for extended return objects. These would also be affected by this anomaly. **************************************************************** From: Tucker Taft Sent: Thursday, January 17, 2008 2:33 PM I agree with you with respect to one *subtype* being statically compatible with another. I think the definition of a *constraint* being statically compatible with a subtype is correct. Here is the last sentence of 4.9.1(4): ... One subtype is statically compatible with a second subtype if the constraint of the first is statically compatible with the second subtype. Since A being compatible with B implies that the set of values satisfying A is a subset of the values satisfying B, to properly handle null exclusion this should be changed to something like: ... One subtype is statically compatible with a second subtype if the constraint of the first is statically compatible with the second subtype{, and in the case of an access type, if the second subtype excludes null, then so does the first}. We don't need to worry about formal access subtypes, since formal and actual must match with respect to null exclusion. **************************************************************** From: Stephen W. Baird Sent: Friday, January 18, 2008 11:51 AM > I agree with you with respect to one *subtype* being > statically compatible with another. I think the > definition of a *constraint* being statically > compatible with a subtype is correct. Agreed. ... > Since A being compatible with B implies that the set of > values satisfying A is a subset of the values satisfying > B, to properly handle null exclusion this should > be changed to something like: > > ... One subtype is statically compatible with a second > subtype if the constraint of the first is statically > compatible with the second subtype{, and in the case > of an access type, if the second subtype excludes null, > then so does the first}. Sounds good to me. ****************************************************************