CVS difference for ais/ai-00231.txt

Differences between 1.11 and version 1.12
Log of other versions for file ais/ai-00231.txt

--- ais/ai-00231.txt	2003/10/29 22:54:09	1.11
+++ ais/ai-00231.txt	2004/01/08 04:16:38	1.12
@@ -1,4 +1,4 @@
-!standard  3.10      (06)                        03-10-22  AI95-00231/06
+!standard  3.10      (06)                        03-12-11  AI95-00231/07
 !standard  3.10      (12)
 !standard  4.6       (49)
 !standard  8.6       (25)
@@ -42,6 +42,18 @@
 Delete paragraph 3.2.2(5).
+Modify 3.7(5) to:
+    discriminant_specification ::=
+        defining_identifier_list : [null_exclusion] subtype_mark [:= default_expression]
+      | defining_identifier_list : access_definition [:= default_expression]
+Modify the first sentence of 3.7(9):
+    The subtype of a discriminant may be defined by {an optional null_exclusion and} a
+    subtype_mark, in which case the subtype_mark shall denote a discrete or access
+    subtype, ...
 Modify 3.10(2) to:
     access_type_definition ::=
@@ -53,7 +65,7 @@
     null_exclusion ::= NOT NULL
     access_definition ::=
-       [null_exclusion] ACCESS general_access_modifier subtype_mark
+       [null_exclusion] ACCESS [general_access_modifier] subtype_mark
 Modify 3.10(12) to:
@@ -92,11 +104,33 @@
 Delete paragraph 4.2(7) which says that anonymous access types don't
 have a null value.
+Replace 4.6(49) with:
+    If the operand value is null, the result of the conversion is the null
+    value of the target type.
-Modify 4.6(49) to:
+Add to the end of 4.6(51):
     If the target subtype excludes the null value, then a check is made that
-    the value of the operand is not null; if the target subtype includes null,
-    then the result of the conversion is null if the operand value is null.
+    the value is not null.
+Change 4.9.1(2):
+    A subtype statically matches another subtype of the same type if they have
+    statically matching constraints{, and, for access subtypes, either both or
+    neither exclude null}. Two anonymous access{-to-object} subtypes statically
+    match if their designated subtypes statically match{, and either both or
+    neither exclude null, and either both or neither are access-to-constant}.
+Modify 6.1(15):
+    parameter_specification ::=
+        defining_identifier_list : mode [null_exclusion] subtype_mark [:= default_expression]
+      | defining_identifier_list : access_definition [:= default_expression ]
+Modify 6.1(23):
+    The nominal subtype of a formal parameter is the subtype [denoted]
+    {determined} by the {optional null_exclusion and the} subtype_mark, or
+    defined by the access_definition, in the parameter_specification.
 Modify 8.5.1(4) to include a
 legality rule that requires the access_definition to be
@@ -107,6 +141,16 @@
 permitted, with the expected rules (i.e. it is illegal to convert an
 access-to-constant to access-to-variable).
+Add after 12.5.1(10)
+  * If the ancestor subtype is an access subtype, the actual subtype shall
+    exclude null if and only if the ancestor subtype excludes null.
+Add to the end of 12.5.4(4):
+    If and only if the formal subtype excludes null, the actual subtype shall
+    exclude null.
     type Non_Null_Ptr is not null access T;
@@ -148,8 +192,8 @@
 T". Note that there is no upward incompatibility for controlling access
 parameters; they always have null-excluding subtypes. Any worrisome loss of
 efficiency due to allowing null for non-controlling access parameters, or
-access discriminants, can be reversed by using an explicity
+access discriminants, can be reversed by using an explicit
 The general ability to specify an access subtype that excludes null for both
 named and anonymous access types can provide useful documentation and higher
@@ -166,6 +210,27 @@
 anonymous access types are always considered "general" access
 types. However, it was felt more confusing to disallow use of "all"
 for anonymous access types, even though it has no effect.
+We chose to require matching of null exclusion in generics.
+For formal derived types, static constraint matching was already
+the case for access subtypes. For formal access types, we claim
+that the paradigm of use for null-excluding access types differs
+dramatically from null-including access types, and hence it is
+not sensible to allow the formal and actual to differ on this
+dimension. It also significantly simplifies generic sharing if
+null exclusion is known statically.
+Note that if one has a generic whose formal includes null,
+and one wants to reuse it with an access subtype that excludes null,
+you can do the instantiation using a null-including subtype of
+the same access type and accomplish the same level of reuse.
+The major advantage of this approach is that the generic can
+still declare default-initialized local variables of the access type,
+without bumping into the null exclusion. The instantiatior only
+cares about null exclusion when values are returned, and these checks
+would still be performed. Forcing the generic itself to operate
+internally obeying null exclusion would make it that much harder to
+reuse the generic.
 !ACATS test

Questions? Ask the ACAA Technical Agent