CVS difference for ai05s/ai05-0062-1.txt
--- ai05s/ai05-0062-1.txt 2007/09/13 02:20:43 1.2
+++ ai05s/ai05-0062-1.txt 2007/12/13 04:39:37 1.3
@@ -1,6 +1,7 @@
-!standard 7.4(6/2) 07-08-21 AI05-0062-1/01
+!standard 7.4(6/2) 07-11-29 AI05-0062-1/02
!class binding interpretation 07-08-21
+!status ARG Approved 8-0-1 06-11-10
!status work item 07-08-21
!status received 07-08-21
@@ -10,8 +11,8 @@
-A full constant for a deferred constant that does not have a null exclusion
-may in fact have such an exclusion.
+A full constant may have a null exclusion even if its associated deferred constant
@@ -32,9 +33,9 @@
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 asymetrical.
+[which is reinforced by AARM note 7.4(7.a.1/2)], which is asymmetrical.
-However, a compiler writer was pointed out that 7.4(6/2) requires that the
+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
@@ -61,9 +62,14 @@
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. Thus, we chose to
+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
+For all of the these reasons, we chose to adjust 7.4(6/2).
Questions? Ask the ACAA Technical Agent