CVS difference for ais/ai-00423.txt

--- ais/ai-00423.txt	2005/03/31 02:28:11	1.1
+++ ais/ai-00423.txt	2005/04/02 02:09:49	1.2
@@ -1,11 +1,17 @@
-!standard 8.5.1(4)                                    05-03-30  AI95-00423/01
+!standard 8.5.1(2)                                    05-03-31  AI95-00423/02
+!standard 8.5.1(4)
 !standard 8.5.4(4)
+!standard 12.4(2)
+!standard 12.4(5)
+!standard 12.4(7)
+!standard 12.4(9)
+!standard 12.6(8)
 !class amendment 05-03-30
 !status work item 05-03-30
 !status received 05-03-30
 !priority High
 !difficulty Easy
-!subject Renaming and null exclusion
+!subject Renaming, null exclusion and formal objects
 
 !summary
 
@@ -13,8 +19,8 @@
 
 !problem
 
-At the Paris meeting, we came up with strangely inconsistent decisions regarding
-the interaction of not null with renamings:
+At the Paris meeting, we came up with strangely inconsistent decisions
+regarding the interaction of "not null" with renamings:
 
 1 - For object renamings, we said that "not null" is not permitted under any
 circumstances in the access_definition of the object_renaming_definition.
@@ -23,20 +29,39 @@
 2 - For subprogram renamings, we said that "not null" is permitted, but is
 essentially ignored (like any subtype-ish property). (AI95-00404)
 
-The first rule has the peculiar consequence that it prevents the user from
-"telling the truth", something that we try to encourage. Consider:
+!proposal
+
+It is clear that we want object renamings and subprogram renamings to be
+handled consistently. However, the rules outlined in the !problem section are
+not ideal because:
+
+1 - Disallowing "not null" (the AI95-00409 option) has the peculiar consequence
+that it prevents the user from "telling the truth", something that we try to
+encourage. Consider:
 
 	X : not null access Integer := ...;
 	Y : access Integer renames X;
 
 while Y is really of a null-excluding subtype, the user cannot write an
-explicit null exclusion. This is unfortunate, as we would like the user to be
-able to put the "correct subtype" here.
-
-!proposal
+explicit null exclusion. This is unfortunate, as we would like them to be able
+to put the "correct subtype" here.
 
-Allow an explicit null exclusion in object and subprogram renamings, but only
-if it doesn't lie.
+2 - Allowing "not null" but ignoring it (the AI95-00405 option) is the Ada 83
+model, but it is generally considered undesirable. If it had not be for
+compatibility, modifying the rules in Ada 95 to rely on the notion of
+statically matching subtypes would have been best. Since null exclusion does
+not create any compatibility issue, it seems that we should "do the right
+thing".
+
+The best approach seems to allow the user to write an explicit null_exclusion
+in object and subprogram renamings, but only if such a null_exclusion doesn't
+lie.
+
+Similar rules should apply to generic subprograms.
+
+Finally, it is curious that anonymous access types are not permitted for
+generic formal objects. This is likely to make it unnecessarily hard to turn a
+nongeneric package into a generic package. This restriction is lifted.
 
 !wording
 
@@ -45,15 +70,54 @@
 
 Add after 8.5.1(4):
 
-In the case of an object_renaming_declaration with an access_definition, a
-null_exclusion shall only appear in the access_definition if the subtype of the
-object_name excludes null.
+For an object_renaming_declaration with an access_definition that has a
+null_exclusion, the subtype of the object_name shall exclude null.
 
 Add after 8.5.4(4):
 
-For a parameter or result type of the subprogram_specification, a
-null_exclusion shall only appear if the subtype of the corresponding parameter
-or result type of the renamed callable entity excludes null.
+For a parameter or result type of the subprogram_specification that has a
+null_exclusion, the subtype of the corresponding parameter or result type of
+the renamed callable entity shall exclude null.
+
+Change 12.4(2) to read:
+
+formal_object_declaration ::=
+    defining_identifier_list : mode [null_exclusion] subtype_mark [:=
+default_expression]; |
+    defining_identifier_list : mode access_definition [:= default_expression];
+
+Change 12.4(5) to read:
+
+For a generic formal object of mode in out, the type of the actual shall resolve
+to the type determined by the subtype_mark, or for a formal_object_declaration
+with an access_definition, to a specific anonymous access type which in the case
+of an access-to-object type shall have the same designated type as that of the
+access_definition and in the case of an access-to-subprogram type shall have a
+designated profile which is subtype conformant with that of the
+access_definition.
+
+Add at the end of the second sentence of 12.4(7):
+
+...is allowed; furthermore, for a formal_object_declaration with an
+access_definition that has a null_exclusion, the subtype of the actual shall
+exclude null.
+
+Change 12.4(9) to read:
+
+A formal_object_declaration declares a generic formal object. The default mode
+is in. For a formal object of mode in, the nominal subtype is the one denoted
+by the subtype_mark {or access_definition} in the declaration of the formal.
+For a formal object of mode in out, its type is determined by the subtype_mark
+{or access_definition} in the declaration; its nominal subtype is nonstatic,
+even if the subtype_mark denotes a static subtype; for a composite type, its
+nominal subtype is unconstrained if the first subtype of the type is
+unconstrained[, even if the subtype_mark denotes a constrained subtype].
+
+Add after 12.6(8):
+
+For a parameter or result type of the formal_subprogram_declaration that has a
+null_exclusion, the subtype of the corresponding parameter or result type of
+the actual shall exclude null.
 
 !discussion