Version 1.6 of ai05s/ai05-0062-1.txt

Unformatted version of ai05s/ai05-0062-1.txt version 1.6
Other versions for file ai05s/ai05-0062-1.txt

!standard 7.4(6/2) 08-04-18 AI05-0062-1/03
!standard 7.4(7.1/2)
!class binding interpretation 07-08-21
!status Amendment 201Z 08-11-26
!status WG9 Approved 08-06-20
!status ARG Approved 8-0-1 06-11-10
!status work item 07-08-21
!status received 07-08-21
!priority Low
!difficulty Easy
!qualifier Error
!subject Null exclusions and deferred constants

!summary

A full constant may have a null exclusion even if its associated deferred constant does not.

!question

ACATS 3.0 test B740002 has the following example:

package B740002 is

type Priv_Comp is private;

type Acc_to_Priv is access all Priv_Comp;

Cnst_Priv_22 : constant Acc_to_Priv;

private

type Priv_Comp is ... Priv_Obj : aliased Priv_Comp;

Cnst_Priv_22 : constant not null Acc_to_Priv := Priv_Obj'access; -- OK?

end B740002;

The test writer thought that this constant was legal based on the wording of 7.4(7.1/2) [which is reinforced by AARM note 7.4(7.a.1/2)], which is asymmetrical.

However, a compiler writer has pointed out that 7.4(6/2) requires that the subtype_indications statically match, and that the subtype_indications include the null_exclusion. Note that this is different than renames and parameters, where the null_exclusion is separate from the subtype_mark, and thus matching only applies to that subtype_mark.

What is the intent here?

!recommendation

(See Summary.)

!wording

In 7.4(6/2), change

...then the {constraint}[subtype] defined by the subtype_indication in the full declaration shall match it statically. ...

!discussion

The net effect of the current rules is that the static matching requirement of 7.4(6/2) makes 7.4(7.1/2) completely redundant and unnecessary. Thus, the easiest fix is to delete 7.4(7.1/2).

However, it is clear that it was intended that the explicit null_exclusions would not have to match (as is the case for other cases, like renames). This also would be consistent with the handling of unconstrained subtypes.

Moreover, this is a useful capability. If a package declares a private type whose full type is an access type, a null exclusion would not be allowed on a deferred constant for the private type; but it still might make sense on the full constant definition.

for all of the these reasons, we chose to adjust 7.4(6/2).

!corrigendum 7.4(6/2)

Replace the paragraph:

If the deferred constant declaration includes a subtype_indication that defines a constrained subtype, then the subtype defined by the subtype_indication in the full declaration shall match it statically. On the other hand, if the subtype of the deferred constant is unconstrained, then the full declaration is still allowed to impose a constraint. The constant itself will be constrained, like all constants;

by:

If the deferred constant declaration includes a subtype_indication that defines a constrained subtype, then the constraint defined by the subtype_indication in the full declaration shall match it statically. On the other hand, if the subtype of the deferred constant is unconstrained, then the full declaration is still allowed to impose a constraint. The constant itself will be constrained, like all constants;

!ACATS Test

Replace this case in the ACATS B-Test B740002.

!appendix


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

Questions? Ask the ACAA Technical Agent