CVS difference for ais/ai-00218.txt

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

--- ais/ai-00218.txt	2001/05/26 02:55:11	1.7
+++ ais/ai-00218.txt	2001/09/08 01:42:47	1.8
@@ -1,4 +1,4 @@
-!standard 8.3(9-13)                                   01-05-18  AI95-00218/05
+!standard 8.3(9-13)                                   01-09-07  AI95-00218/06
 !standard 6.1(1)
 !class amendment 99-03-23
 !status ARG approved 7-0-1  01-05-18
@@ -15,22 +15,22 @@
 
 !problem
 
-Subtle bugs result from mistakes in the profile of an overriding subprogram. For
-example:
+Subtle bugs result from mistakes in the profile of an overriding subprogram.
+For example:
 
 with Ada.Finalization;
 package Root is
     type Root_Type is new Ada.Finalization.Controlled with null record;
     procedure Do_Something (Object : in out Root_Type;
-                            Data : in Natural); -- (1)
-    procedure Finalize (Object : in out Root_Type);
+                            Data : in Natural);    -- (1)
+    procedure Finalize (Object : in out Root_Type);-- (2)
 end Root;
 
 with Root;
 package Leaf is
    type Derived_Type is new Root.Root_Type with null record;
    procedure Do_Something (Object : in out Root_Type;
-                           Data : in Boolean); -- (3)
+                           Data : in Boolean);     -- (3)
    procedure Finalise (Object : in out Root_Type); -- (4)
         -- Note: Alternative spelling of "Finalize".
 end Leaf;
@@ -45,7 +45,7 @@
 
 Assume the programmer intended (3) and (4) to override (1) and (2), but made
 subtle declaration errors. Because (1) and (3) are not homographs, the
-declaration of (3) is legal. However, (3) does not override (1), as intended.
+declaration of (3) is legal. However, (3) does not override (1) as intended.
 Therefore, the call in Sample calls the wrong routine. Similarly, the
 incorrect declaration of "Finalise" (4) does not override (2). Thus, the
 finalization of Sample.Obj will call the wrong routine.
@@ -111,9 +111,9 @@
 Pragma Explicit_Overriding is a configuration pragma.
 
 Pragmas Overriding and Optional_Overriding shall immediately follow (except
-for other pragmas) the declaration for a primitive operation. The optional
+for other pragmas) the declaration of a primitive operation. The optional
 designator of a pragma Overriding or Optional_Overriding shall be the same as
-the designator of the operation which it follows. Only one of pragmas
+the designator of the operation which it follows. Only one of the pragmas
 Overriding and Optional_Overriding shall be given for a single primitive
 operation.
 
@@ -183,7 +183,7 @@
 single name are overridden as a group.
 
 We considered adding syntax rather than defining pragma Overriding. Syntax was
-determined to be too heavyweight a solution for an amendment. One idea
+determined to be too heavyweight a solution for this problem. One idea
 considered using existing keywords was: subprogram_specification is not new;
 These ideas were not considered satisfactory; it was felt that proper syntax
 would need a new reserved word "overriding" or "redefined". That is much too
@@ -203,13 +203,13 @@
 constructor (also named "Create") with additional parameters, as well
 as overriding the existing constructor (giving appropriate defaults for the
 new parameters). It is critical that these pragmas handle this case.
-The solution adopted is that the pragmas only apply to the operation which
+The solution adopted is that the pragmas only apply to the operations which
 immediately precede them. This makes it important that these pragmas are not
 accidentally separated from the subprogram declaration. The optional
 designator in the pragma provides a means to ensure that this does not happen.
 
-This semantics means that the pragmas can be treated almost as a part of the
-subprogram declaration. This eases the implementation, as a compiler can
+The chosen semantics means that the pragmas can be treated almost as a part of
+the subprogram declaration. This eases the implementation, as a compiler can
 determine what kind of declaration it is processing before it starts doing so.
 (Without this rule, an implementation must postpone error messages until it
 reaches the next declaration. Since the next declaration could be almost
@@ -236,7 +236,8 @@
     pragma Overriding (Op); -- OK.
     package Nested is
         type NNT is new T;
-        procedure Op (Y : NNT); -- Illegal (Overriding or
+        procedure Op (Y : NNT); -- Illegal because the body of Nested has
+                                -- visibility on primitive 'Op' (Overriding or
                                 -- Optional_Overriding needs to be given)
     end Nested;
 private
@@ -250,20 +251,19 @@
 end P.C;
 
 Another use for Optional_Overriding exists in this example; it can be used
-here is avoid breaking the abstraction (privateness) of the original type P.
+here to avoid breaking the abstraction (privateness) of the original type P.T.
 
 The pragmas Overriding and Optional_Overriding are checked in a
 generic_declaration. We do this because we do not want these pragmas to be
-part of the "contract" of a generic.
+part of the "contract" of a generic. To see how this could happen, consider
+the following example:
 
-For instance:
-
 generic
     type GT is tagged private;
 package Gen is
     type DGT is new GT with private;
     procedure Op (Z : DGT);
-    pragma Overriding (Op); -- Error: Don't override anything.
+    pragma Overriding (Op); -- Error: Doesn't override anything.
 private
     -- ...
 end Gen;
@@ -291,7 +291,7 @@
 pragmas to be mixed with those that do not.
 
 In a mixed environment, it is important that units be checked based on the
-environment that they were designed for. Thus, generic instantiations are
+environment for which they were designed. Thus, generic instantiations are
 checked based on whether pragma Explicit_Overriding applies to the generic
 unit, and not whether it applies to the instantiation.
 
@@ -383,3 +383,26 @@
 programmer, ]violat{ed}[ing] the Ada design principle[s] of least surprise. (Introduction, paragraph 8).
 
 *************************************************************
+
+!from Randy Brukardt 05-25-01
+
+Following are my notes on this AI from the Leuven ARG meeting (May 2001).
+All of these changes have been made to the AI.
+
+Only minor editorial changes were needed. The last paragraph of the wording
+must be corrected as follows:
+
+Explicit_Overriding applies if and only if it applies to {the} generic unit.
+At a [declaration]{place} where a ...
+
+and the following typo must be fixed:
+
+... an overrid[d]ing declaration.
+
+Steve M. is concerned that configuration pragmas are partition-wide. Erhard
+replies that they are not defined that way in the RM. Moreover, it is very
+useful semantics to localize the effects of the pragma, as library code might
+be part of the partition, but not adhere to the use of the Overrides pragma.
+
+*************************************************************
+

Questions? Ask the ACAA Technical Agent