CVS difference for ais/ai-00423.txt

Differences between 1.6 and version 1.7
Log of other versions for file ais/ai-00423.txt

--- ais/ai-00423.txt	2005/05/10 20:23:39	1.6
+++ ais/ai-00423.txt	2005/06/16 23:47:45	1.7
@@ -7,6 +7,8 @@
 !standard 12.4(9)
 !standard 12.6(8)
 !class amendment 05-03-30
+!status Amendment 200Y 05-05-10
+!status ARG Approved 9-0-1  05-04-18
 !status work item 05-03-30
 !status received 05-03-30
 !priority High
@@ -90,33 +92,46 @@
 
 !wording
 
+Change 8.5.1(2):
+
+   object_renaming_declaration ::=
+       defining_identifier : [null_exclusion] subtype_mark renames object_name;
+     | defining_identifier : access_definition renames object_name;
+
 Remove the syntax rule added by AI95-00409 after 8.5.1(2/2) (that's the one
-which makes a null exclusion illegal).
+which makes a null_exclusion illegal).
 
 Add after 8.5.1(4):
 
-For an object_renaming_declaration with an access_definition that has a
-null_exclusion:
+For an object_renaming_declaration with a null_exclusion or an
+access_definition that has a null_exclusion:
 
-o  if the object_renaming_declaration occurs within the body of a generic unit,
-   and the object_name denotes a generic formal object of that generic
-   unit, then the declaration of that formal object shall have a
+o  if the object_renaming_declaration occurs within the body of a generic unit
+   G or within the body of a generic unit declared within the declarative
+   region of the generic unit G, and the object_name denotes a generic formal
+   object of G, then the declaration of that formal object shall have a
    null_exclusion;
 
-o  otherwise, the subtype of the object_name shall exclude the null value.
+o  otherwise, the subtype of the object_name shall exclude null. In addition to
+   the places where Legality Rules normally apply (see 12.3), this rule
+   applies also in the private part of an instance of a generic unit.
 
 Add after 8.5.4(4):
 
-For a parameter or result type of the subprogram_specification that has a
-null_exclusion:
+For a parameter or result subtype of the subprogram_specification that has
+an explicit null_exclusion:
 
 o   if the subprogram_renaming_declaration occurs within the body of a generic
-    unit, and the callable_entity_name denotes a generic formal subprogram of
-    that generic unit, then the corresponding parameter or result type of that
-    formal subprogram shall have a null_exclusion;
+    unit G or within the body of a generic unit declared within the declarative
+    region of the generic unit G, and the callable_entity_name denotes a
+    generic formal subprogram of G, then the corresponding parameter or
+    result subtype of that formal subprogram shall have a null_exclusion;
 
 o   otherwise, the subtype of the corresponding parameter or result type of the
-    renamed callable entity shall exclude the null value.
+    renamed callable entity shall exclude null. In addition to
+    the places where Legality Rules normally apply (see 12.3), this rule
+    applies also in the private part of an instance of a generic unit.
+
 
 Change 12.4(2) to read:
 
@@ -137,26 +152,30 @@
 
 Add after 12.4(7):
 
-In the case where the type is defined by an access_definition, the type of the
-actual and the type of the formal:
+In the case where the type of the formal is defined by an access_definition,
+the type of the actual and the type of the formal:
 
 o   shall both be access-to-object types with statically matching designated
-    subtypes and with both or neither being access-to-constant types; and
+    subtypes and with both or neither being access-to-constant types; or
 
 o   shall both be access-to-subprogram types with subtype conformant designated
     profiles.
 
-For a formal_object_declaration with an access_definition that has a
-null_exclusion:
+For a formal_object_declaration with a null_exclusion or an access_definition
+that has a null_exclusion:
 
-o   for an instantiation that occurs within the body of a generic unit, and
-    the actual denotes a generic formal object of that generic unit, then
-    the declaration of that formal object shall have a null_exclusion;
+o   for an instantiation that occurs within the body of a generic unit or
+    within the body of a generic unit declared within the declarative region of
+    the generic unit, and the actual denotes a generic formal object of that
+    generic unit, then the declaration of that formal object shall have a
+    null_exclusion;
+
+o   otherwise, the subtype of the actual shall exclude null. In addition to
+    the places where Legality Rules normally apply (see 12.3), this rule
+    applies also in the private part of an instance of a generic unit.
 
-o   otherwise, the subtype of the actual shall exclude the null value.
+Change 12.4(9) to read: (This includes the change from AI-255)
 
-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.
@@ -164,20 +183,23 @@
 {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].
+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:
+For a parameter or result type of a formal_subprogram_declaration that has an
+explicit null_exclusion:
 
-o   for an instantiation that occurs within the body of a generic unit, and
-    the actual denotes a generic formal subprogram of that generic unit, then
-    the corresponding parameter or result type of that formal subprogram shall
-    have a null_exclusion,
+o   for an instantiation that occurs within the body of a generic unit or
+    within the body of a generic unit declared within the declarative region of
+    the generic unit, and the actual denotes a generic formal subprogram of
+    that generic unit, then the corresponding parameter or result type of that
+    formal subprogram shall have a null_exclusion;
 
 o   otherwise, the subtype of the corresponding parameter or result type of the
-    actual shall exclude the null value.
+    actual shall exclude null. In addition to
+    the places where Legality Rules normally apply (see 12.3), this rule
+    applies also in the private part of an instance of a generic unit.
 
 !discussion
 
@@ -185,12 +207,360 @@
 
 !example
 
+!corrigendum 8.5.1(2)
 
---!corrigendum
+@drepl
+@xcode<@fa<object_renaming_declaration ::=
+    defining_identifier : subtype_mark >@ft<@b<renames>>@fa< object_name;>>
+@dby
+@xcode<@fa<object_renaming_declaration ::=
+    defining_identifier : [null_exclusion] subtype_mark >@ft<@b<renames>>@fa< object_name;
+  | defining_identifier : access_definition >@ft<@b<renames>>@fa< object_name;>>
+
+!corrigendum 8.5.1(4)
+
+@dinsa
+The renamed entity shall be an object.
+@dinss
+For an @fa<object_renaming_declaration> with a @fa<null_exclusion> or an
+@fa<access_definition> that has a @fa<null_exclusion>:
+
+@xbullet<if the @fa<object_renaming_declaration> occurs within the body of a
+generic unit @i<G> or within the body of a generic unit declared within the
+declarative region of the generic unit @i<G>, and the @i<object_>@fa<name>
+denotes a generic formal object of @i<G>, then the declaration of that formal
+object shall have a @fa<null_exclusion>;>
+
+@xbullet<otherwise, the subtype of the @i<object_>@fa<name> shall exclude null.
+In addition to the places where Legality Rules normally apply (see 12.3), this
+rule applies also in the private part of an instance of a generic unit.>
+
+!corrigendum 8.5.4(4)
+
+@dinsa
+The profile of a renaming-as-declaration shall be mode-conformant with that of
+the renamed callable entity.
+@dinss
+For a parameter or result subtype of the @fa<subprogram_specification> that
+has an explicit @fa<null_exclusion>:
+
+@xbullet<if the @fa<subprogram_renaming_declaration> occurs within the body of
+a generic unit @i<G> or within the body of a generic unit declared within the
+declarative region of the generic unit @i<G>, and the
+@i<callable_entity_>@fa<name> denotes a generic formal
+subprogram of @i<G>, then the corresponding parameter or result
+subtype of that formal subprogram shall have a @fa<null_exclusion>;>
+
+@xbullet<otherwise, the subtype of the corresponding parameter or result type
+of the renamed callable entity shall exclude null. In addition to
+the places where Legality Rules normally apply (see 12.3), this rule
+applies also in the private part of an instance of a generic unit.>
+
+!corrigendum 12.4(2)
+
+@drepl
+@xcode<@fa<formal_object_declaration ::=
+    defining_identifier_list : mode subtype_mark [:= default_expression]>>
+@dby
+@xcode<@fa<formal_object_declaration ::=
+    defining_identifier_list : mode [null_exclusion] subtype_mark [:= default_expression]
+  | defining_identifier_list : mode access_definition [:= default_expression];>>
+
+
+!corrigendum 12.4(5)
+@drepl
+For a generic formal object of mode @b<in out>, the type of the actual shall
+resolve to the type of the formal.
+@dby
+For a generic formal object of mode @b<in out>, the type of the actual shall
+resolve to the type determined by the @fa<subtype_mark>, or for a
+@fa<formal_object_declaration> with an @fa<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 @fa<access_definition> and in the case
+of an access-to-subprogram type shall have a designated profile which is type
+conformant with that of the @fa<access_definition>.
+
+
+!corrigendum 12.4(7)
+
+@dinsa
+For a generic formal object of mode @b<in>, the actual shall be an
+@fa<expression>. For a generic formal object of mode @b<in out>, the actual
+shall be a name that denotes a variable for which renaming is allowed (see
+8.5.1).
+@dinss
+In the case where the type of the formal is defined by an
+@fa<access_definition>, the type of the actual and the type of the formal:
+
+@xbullet<shall both be access-to-object types with statically matching
+designated subtypes and with both or neither being access-to-constant types;
+or>
+
+@xbullet<shall both be access-to-subprogram types with subtype conformant
+designated profiles.>
+
+For a @fa<formal_object_declaration> with a @fa<null_exclusion> or an
+@fa<access_definition> that has a @fa<null_exclusion>:
+
+@xbullet<for an instantiation that occurs within the body of a generic unit or
+within the body of a generic unit declared within the declarative region of
+the generic unit, and the actual denotes a generic formal object of that
+generic unit, then the declaration of that formal object shall have a
+@fa<null_exclusion>;>
+
+@xbullet<otherwise, the subtype of the actual shall exclude null. In addition
+to the places where Legality Rules normally apply (see 12.3), this rule
+applies also in the private part of an instance of a generic unit.>
+
+!corrigendum 12.4(9)
+
+@drepl
+A @fa<formal_object_declaration> declares a generic formal object. The default
+mode is @b<in>. For a formal object of mode @b<in>, the nominal subtype is the
+one denoted by the @fa<subtype_mark> in the declaration of the formal. For a
+formal object of mode @b<in out>, its type is determined by the
+@fa<subtype_mark> in the declaration; its nominal subtype is nonstatic, even
+if the @fa<subtype_mark> denotes a static subtype.
+@dby
+A @fa<formal_object_declaration> declares a generic formal object. The default
+mode is @b<in>. For a formal object of mode @b<in>, the nominal subtype is the
+one denoted by the @fa<subtype_mark> or @fa<access_definition> in the
+declaration of the formal. For a formal object of mode @b<in out>, its type
+is determined by the @fa<subtype_mark> or @fa<access_definition> in the
+declaration; its nominal subtype is nonstatic, even
+if the @fa<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 @fa<subtype_mark> denotes a constrained subtype.
 
+!corrigendum 12.6(8)
+
+@dinsa
+The profile of the formal and actual shall be mode-conformant.
+@dinss
+For a parameter or result subtype of a @fa<formal_subprogram_declaration> that
+has an explicit @fa<null_exclusion>:
+
+@xbullet<for an instantiation that occurs within the body of a generic unit or
+within the body of a generic unit declared within the declarative region of
+the generic unit, and the actual denotes a generic formal subprogram of
+that generic unit, then the corresponding parameter or result type of that
+formal subprogram shall have a @fa<null_exclusion>;>
+
+@xbullet<otherwise, the subtype of the corresponding parameter or result type
+of the actual shall exclude null. In addition to the places where Legality
+Rules normally apply (see 12.3), this rule applies also in the private part
+of an instance of a generic unit.>
+
 !ACATS test
 
 
 !appendix
+
+****************************************************************
+
+From: Bob Duff
+Sent: Saturday, June 11, 2005  9:50 PM
+
+AARM version 1.19.
+
+8.5.1(4.4/2):
+
+4.3/2 {AI95-00423-01} For an object_renaming_declaration with a null_exclusion
+or an access_definition that has a null_exclusion:
+
+4.4/2 if the object_renaming_declaration occurs within the body of a generic
+      unit or within the body of a generic unit declared within the
+      declarative region of the generic unit, and the object_name denotes a
+                            ^^^
+      generic formal object of that generic unit, then the declaration of that
+                               ^^^^
+      formal object shall have a null_exclusion;
+
+I find this completely mystifying.  I mean, how can you be "within the body of a
+generic unit declared within the declarative region of the generic unit" without
+simply being "within the body of a generic unit"?
+
+What do "the" and "that" refer to, above?
+
+I read the AARM example, and I am still not sure what this rule is
+getting at.
+
+Similar wording appears in 8.5.4(4.2/2):
+
+4.2/2 if the subprogram_renaming_declaration occurs within the body of a
+      generic unit or within the body of a generic unit declared within the
+      declarative region of the generic unit, and the callable_entity_name
+      denotes a generic formal subprogram of that generic unit, then the
+      corresponding parameter or result type of that formal subprogram shall
+      have a null_exclusion;
+
+*************************************************************
+
+From: Pascal Leroy
+Sent: Tuesday, June 14, 2005   1:34 AM
+
+I agree that this sounds rather incomprehensible to me, and I believe that
+it was extensively rewritten by Randy after the last meeting, so we'll
+need to wait for his reply.  (Apparently he has mail problems because I
+just got 6 messages from him in the last 2 minutes.)
+
+*************************************************************
+
+From: Randy Brukardt
+Sent: Tuesday, June 14, 2005   1:56 AM
+
+Pascal writes:
+
+> I agree that this sounds rather incomprehensible to me, and I believe that
+> it was extensively rewritten by Randy after the last meeting, so we'll
+> need to wait for his reply.  (Apparently he has mail problems because I
+> just got 6 messages from him in the last 2 minutes.)
+
+Naah, I'm very productive just before going home. :-)
+
+Actually, I had a bad mail backup because of a mailing list (not one of
+mine!) that started spewing messages every minute. It just got cleared out,
+and all should be fine. Of course, I'm now going to bed.
+
+One of those six messages ought to be the reply you're looking for - wrote
+it 4 hours ago.
+
+*************************************************************
+
+From: Randy Brukardt
+Sent: Monday, June 13, 2005   9:36 PM
+
+Bob is mystified:
+
+> 8.5.1(4.4/2):
+>
+> 4.3/2 {AI95-00423-01} For an object_renaming_declaration with a
+> null_exclusion
+> or an access_definition that has a null_exclusion:
+>
+> 4.4/2 if the object_renaming_declaration occurs within the body
+> of a generic
+>       unit or within the body of a generic unit declared within the
+>       declarative region of the generic unit, and the object_name
+> denotes a
+>                             ^^^
+>       generic formal object of that generic unit, then the
+> declaration of that
+>                                ^^^^
+>       formal object shall have a null_exclusion;
+>
+> I find this completely mystifying.  I mean, how can you be "within the body of a
+> generic unit declared within the declarative region of the generic unit" without
+> simply being "within the body of a generic unit"?
+
+You could be in the child of a generic unit; the child can reference the
+parent's formals. I even mentioned that in the AARM note:
+"The rule is so complex because it has to apply to bodies of child generics
+as well."
+
+That is, if you had a generic child Inner (now you know why the parent was
+called "Outer"):
+
+generic
+package Outer.Inner is
+...
+end Outer.Inner;
+
+package body Outer.Inner is
+  D : not null Acc_I renames Outer.B; -- Illegal.
+end Outer.Inner;
+
+> What do "the" and "that" refer to, above?
+
+The generic unit that has the formal. The generic body may be different (if
+it is a child, as above). This wording is copied from 3.10.2(32) (the
+changed text), where we originally discovered this problem with
+assume-the-worst rules.
+
+> I read the AARM example, and I am still not sure what this rule is
+> getting at.
+
+The AARM example is trying to explain the need for the rule, not why it has
+to be so complex.
+
+> Similar wording appears in 8.5.4(4.2/2):
+>
+> 4.2/2 if the subprogram_renaming_declaration occurs within the body of a
+>       generic unit or within the body of a generic unit declared within the
+>       declarative region of the generic unit, and the callable_entity_name
+>       denotes a generic formal subprogram of that generic unit, then the
+>       corresponding parameter or result type of that formal subprogram shall
+>       have a null_exclusion;
+
+And in 3.10.2(32). There, the AARM note includes:
+"Declared within the declarative region of the generic" is referring to
+child and nested generic units.
+Perhaps I have to add that to each rename AARM note?
+
+If you want to try to reword this, be my guest. :-) We've tried several
+times to make it better, but it seems to defy improvement. It's possible
+that the adaption of the wording to renames could be improved, too. Ideas
+welcome.
+
+*************************************************************
+
+From: Randy Brukardt
+Sent: Wednesday, June 15, 2005   8:39 PM
+
+Nobody is trying to improve this wording, but no one likes it.
+
+...
+
+The usual way to fix such wording is to introduce a name for the unit, that
+might help here because there are two different generic units involved.
+
+4.4/2 if the object_renaming_declaration occurs within the body of a generic
+       unit G or within the body of a generic unit declared within the
+       declarative region of the generic unit G, and the object_name denotes a
+       generic formal object of G, then the declaration of that
+       formal object shall have a null_exclusion;
+
+Does this help? (Presuming you already understand the issue with the child
+units).
+
+> > Similar wording appears in 8.5.4(4.2/2):
+...
+
+4.2/2 if the subprogram_renaming_declaration occurs within the body of a
+      generic unit G or within the body of a generic unit declared within the
+      declarative region of the generic unit G, and the callable_entity_name
+      denotes a generic formal subprogram of G, then the
+      corresponding parameter or result subtype of that formal subprogram shall
+      have a null_exclusion;
+
+Better?
+
+*************************************************************
+
+From: Pascal Leroy
+Sent: Thursday, June 16, 2005  10:25 AM
+
+> 4.4/2 if the object_renaming_declaration occurs within the
+> body of a generic
+>        unit G or within the body of a generic unit declared within the
+>        declarative region of the generic unit G, and the
+> object_name denotes a
+>        generic formal object of G, then the declaration of that
+>        formal object shall have a null_exclusion;
+
+I think it's much better.
+
+> 4.2/2 if the subprogram_renaming_declaration occurs within
+> the body of a
+>       generic unit G or within the body of a generic unit
+> declared within the
+>       declarative region of the generic unit G, and the
+> callable_entity_name
+>       denotes a generic formal subprogram of G, then the
+>       corresponding parameter or result subtype of that
+> formal subprogram shall
+>       have a null_exclusion;
+
+Much better too.
 
 *************************************************************

Questions? Ask the ACAA Technical Agent