Version 1.3 of ai05s/ai05-0086-1.txt

Unformatted version of ai05s/ai05-0086-1.txt version 1.3
Other versions for file ai05s/ai05-0086-1.txt

!standard 4.9.1(4/2) 08-01-28 AI05-0086-1/01
!class binding interpretation 08-01-28
!status ARG Approved 8-0-1 08-02-10
!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)

Replace the paragraph:

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.

by:

!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.

****************************************************************

Questions? Ask the ACAA Technical Agent