!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) @drepl @xbullet that defines a constrained subtype, then the subtype defined by the @fa 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;> @dby @xbullet that defines a constrained subtype, then the constraint defined by the @fa 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. !ASIS No change needed. !appendix ****************************************************************