CVS difference for ais/ai-20218.txt

Differences between 1.17 and version 1.18
Log of other versions for file ais/ai-20218.txt

--- ais/ai-20218.txt	2004/11/25 03:13:31	1.17
+++ ais/ai-20218.txt	2005/06/16 23:47:49	1.18
@@ -1,4 +1,4 @@
-!standard 8.3(26)                                    04-11-24  AI95-00218-03/08
+!standard 8.3(26)                                    05-05-27  AI95-00218-03/09
 !standard 2.9(2)
 !standard 6.1(2)
 !standard 6.1(3)
@@ -112,7 +112,7 @@
 precisely where the check is made. It might be that the operation is
 not visibly overloaded but turns out to be overloaded when the full
 type declaration occurs. Therefore, we define the checks to be
-made at the point of the declaration or clause with the prefix. For the case
+made at the place of the declaration or clause with the prefix. For the case
 in question, no prefix would be given on the visible declaration. The prefix
 could be given on the body, if desired.
 
@@ -124,7 +124,6 @@
 
 Change the syntax in 6.1 to read:
 
-overriding_indicator ::= [not] overriding
 subprogram_declaration ::=
     [overriding_indicator]
     subprogram_specification;
@@ -141,24 +140,35 @@
 Add the following after 6.1(30):
 
 An overriding_indicator is used to indicate whether overriding is intended.
-See 8.3, "Visibility".
+See 8.3.1, "Overriding Indicators".
+
+Add a new subclause 8.3.1:
+
+8.3.1 Overriding indicators
 
-Add to 8.3 after paragraph 26:
+An overriding_indicator is used to declare that an operation is
+intended to override (or not override) an inherited operation.
+
+Syntax
+
+overriding_indicator ::= [not] overriding
 
+Legality Rules
+
 If a subprogram_declaration, abstract_subprogram_declaration, subprogram_body,
 subprogram_body_stub, subprogram_renaming_declaration, or generic_instantiation
 of a subprogram has an overriding_indicator, then:
   * the operation shall be a primitive operation for some type;
   * if the overriding_indicator is "overriding", then the operation shall
-    override a homograph at the point of the declaration or body;
+    override a homograph at the place of the declaration or body;
   * if the overriding_indicator is "not overriding", then the operation shall
-    not override any homograph (at any point).
+    not override any homograph (at any place).
 In addition to the places where Legality Rules normally apply, these rules also
 apply in the private part of an instance of a generic unit.
 
 AARM Note:
 The "overriding" and "not overriding" rules differ slightly. For "overriding",
-we want the indicator to reflect the overriding state at the point of the
+we want the indicator to reflect the overriding state at the place of the
 declaration; otherwise the indicator would be 'lying'. Whether a homograph is
 implicitly declared after the declaration (see 7.3.1 to see how this can happen)
 has no impact on this check. However, "not overriding" is different; 'lying'
@@ -169,6 +179,8 @@
 
 The 'no lying' rules are needed to prevent a subprogram_declaration and
 subprogram_body from having contradictory overriding_indicators.
+End AARM Notes.
+
 
 Change the syntax in 8.5.4 to read
 
@@ -634,8 +646,7 @@
 @drepl
 @xcode<@fa<subprogram_declaration ::= subprogram_specification ;>>
 @dby
-@xcode<@fa<overriding_indicator ::= [>@ft<@b<not>>@fa<] >@ft<@b<overriding>>@fa<
-subprogram_declaration ::=
+@xcode<@fa<subprogram_declaration ::=
     [overriding_indicator]
     subprogram_specification ;>>
 
@@ -674,35 +685,30 @@
 "Abstract Types and Subprograms".
 @dinst
 An @fa<overriding_indicator> is used to indicate whether overriding is
-intended. See 8.3, "Visibility".
+intended. See 8.3.1, "Overriding Indicators".
 
-!corrigendum 8.3(26)
+!corrigendum 8.3.1(1)
 
-@dinsa
-A non-overridable declaration is illegal if there is a homograph occurring
-immediately within the same declarative region that is visible at the place
-of the declaration, and is not hidden from all visibility by the non-overridable
-declaration. In addition, a type extension is illegal if somewhere within
-its immediate scope it has two visible components with the same name. Similarly,
-the @fa<context_clause> for a @fa<subunit> is illegal if it
-mentions (in a @fa<with_clause>) some library unit, and there is a homograph of
-the library unit that is visible at the place of the corresponding stub, and
-the homograph and the mentioned library unit are both declared immediately
-within the same declarative region. These rules also apply to dispatching
-operations declared in the visible part of an instance of a generic unit.
-However, they do not apply to other overloadable declarations in an instance;
-such declarations may have type conformant profiles in the instance, so long
-as the corresponding declarations in the generic were not type conformant.
-@dinss
+@dinsc
+
+An @fa<overriding_indicator> is used to declare that an operation is
+intended to override (or not override) an inherited operation.
+
+@i<@s8<<Syntax>>
+
+@xcode<@fa<overriding_indicator ::= [>@ft<@b<not>>@fa<] >@ft<@b<overriding>>>
+
+@i<@s8<<Legality Rules>>
+
 If a @fa<subprogram_declaration>, @fa<abstract_subprogram_declaration>,
 @fa<subprogram_body>, @fa<subprogram_body_stub>,
 @fa<subprogram_renaming_declaration>, or @fa<generic_instantiation> of a
 subprogram has an @fa<overriding_indicator>, then:
 @xbullet<the operation shall be a primitive operation for some type;>
 @xbullet<if the @fa<overriding_indicator> is @b<overriding>, then the operation
-shall override a homograph at the point of the declaration or body;>
+shall override a homograph at the place of the declaration or body;>
 @xbullet<if the @fa<overriding_indicator> is @b<not overriding>, then the
-operation shall not override any homograph (at any point).>
+operation shall not override any homograph (at any place).>
 In addition to the places where Legality Rules normally apply, these rules also
 apply in the private part of an instance of a generic unit.
 
@@ -1363,6 +1369,104 @@
 
 Thus, I deleted it completely, thus simplifying the presentation quite a bit.
 Comments welcome.
+
+*************************************************************
+
+From: Bob Duff
+Sent: Sunday, June 12, 2005  9:49 AM
+
+I have three questions from my review of 7.6 through 9.
+Here's the first.
+
+AARM version 1.19.
+
+8.3.1(3/2):
+
+3/2 {AI95-00218-03} {AI95-00348-01} {AI95-00397-01} If ... has an
+overriding_indicator, then:
+...
+5/2   if the overriding_indicator is overriding, then the operation shall
+      override a homograph at the point of the declaration or body;
+
+6/2   if the overriding_indicator is not overriding, then the operation shall
+      not override any homograph (at any point).
+
+I'm confused.  If we have:
+
+    package P is
+        type T is tagged private;
+
+        [not] overriding? procedure Finalize(X: in out T);
+    private
+        type T is new Limited_Controlled with...;
+    end P;
+
+Am I allowed to say "overriding" on Finalize(T)?  (I hope so.)
+
+But "declaration or body" could be taken to mean the construct that has the
+overriding_indicator.  And the AARM says "For overriding, we want the indicator
+to reflect the overriding state at the point of the declaration", which would
+seem to imply that overriding is *not* allowed above.
+
+*************************************************************
+
+From: Randy Brukardt
+Sent: Monday, June 13, 2005  9:15 PM
+
+> Am I allowed to say "overriding" on Finalize(T)?  (I hope so.)
+
+No. There was a strong sentiment against indicators ever "lying" or leaking
+private information. And it's obvious (without looking into the private part)
+that there is no overriding going on there.
+
+However, you can put the indicator on the body, presuming you leave it off of
+the routine in the public part. (They can't conflict, and the rules are
+designed to insure that can't happen.)
+
+Moreover, in this case, you don't *really* want to make Finalize visible; and
+of course there is no problem doing the overriding in the private part, in
+which case you could give the indicator there.
+
+> But "declaration or body" could be taken to mean the construct that has the
+> overriding_indicator.  And the AARM says "For overriding, we want the indicator
+> to reflect the overriding state at the point of the declaration", which would
+> seem to imply that overriding is *not* allowed above.
+
+Not only does it imply it, it's quite intended. This stuff took a very long
+time to understand and come to a consensus. Perhaps the consensus would have
+been different had you attended more meetings. :-)
+
+*************************************************************
+
+From: Pascal Leroy
+Sent: Tuesday, June 14, 2005  1:27 AM
+
+> Am I allowed to say "overriding" on Finalize(T)?  (I hope so.)
+
+No, you can't say "overriding" here.  Finalize is not overriding at the
+point of the specification.  Allowing the indicator would leak privacy.
+
+But of course you can (and should) put the indicator on the body of
+Finalize, because at the location of the body surely Finalize is an
+overriding.
+
+I think it all makes sense.  In the situation that you describe,
+indicators should be on the body, because they are mostly addressing an
+implementation issue: you want to make it really sure that you didn't
+mistype the subprogram name.  This should not concern the clients who are
+just assuming that your abstraction is well-behaved.
+
+The situation would be different if T were visibly derived from
+Limited_Controlled.  In this case, it would make sense to advertise the
+fact that you override Finalize, and that this is indeed intentional.
+
+> But "declaration or body" could be taken to mean the
+> construct that has the overriding_indicator.  And the AARM
+> says "For overriding, we want the indicator to reflect the
+> overriding state at the point of the declaration", which
+> would seem to imply that overriding is *not* allowed above.
+
+Yes, that's exactly the intent.
 
 *************************************************************
 

Questions? Ask the ACAA Technical Agent