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.
+
 !example
 
     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
-not_null_constraint.
+access discriminants, can be reversed by using an explicit
+null_exclusion.
 
 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