CVS difference for ais/ai-00218.txt

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

--- ais/ai-00218.txt	2000/11/04 01:10:28	1.5
+++ ais/ai-00218.txt	2000/12/08 00:03:42	1.6
@@ -1,4 +1,4 @@
-!standard 8.3(9-13)                                   99-11-24  AI95-00218/03
+!standard 8.3(9-13)                                   00-12-07  AI95-00218/04
 !standard 6.1(1)
 !class amendment 99-03-23
 !status work item 99-03-23
@@ -31,7 +31,7 @@
    procedure Do_Something (Object : in out Root_Type;
                            Data : in Boolean); -- (3)
    procedure Finalise (Object : in out Root_Type); -- (4)
-        -- Note: British spelling of "Finalize".
+        -- Note: Alternative spelling of "Finalize".
 end Leaf;
 
 with Leaf;
@@ -56,7 +56,7 @@
 reason that the wrong routine is being called is not obvious. In the Finalize
 case, the programmer might even think that the compiler is failing to call
 Finalize at all. These problems have generated many "bug" reports to compiler
-writers, including ones from in their own development teams.
+writers, including ones from their own development teams.
 
 A more serious problem is that it makes maintenance of object-oriented Ada 95
 code much more difficult. Consider a maintenance change to the root class which
@@ -68,8 +68,8 @@
 another. In this case, an inappropriate routine may be called via dispatching,
 and may cause the failure of an abstraction.
 
-In all of these cases, the Ada compiler is being actively harmful to the
-programmer, violating the Ada design principles of least surprise.
+All of these cases violate the Ada design principle of least surprise, as
+described in paragraph 8 of the Introduction to the standard.
 
 !proposal
 
@@ -82,12 +82,12 @@
 existing Ada 95 code. Therefore, we have to introduce an optional solution
 which applies only when the programmer asks for it.
 
-Thus, we introduce three new pragmas, Explicit_Overriding, Overrides, and
-Might_Override. Explicit_Overriding is a configuration pragma which requires
-explicit marking of overriding subprograms. Pragma Overrides is used to mark
-subprograms that are overriding. Pragma Might_Override marks subprograms which
-may or may not be overriding. Unmarked subprograms are new declarations,
-and may not override another routine.
+Thus, we introduce three new pragmas, Explicit_Overriding, Overriding, and
+Optional_Overriding. Explicit_Overriding is a configuration pragma which
+requires explicit marking of overriding subprograms. Pragma Overriding is used
+to mark subprograms that are overriding. Pragma Optional_Overriding marks
+subprograms which may or may not be overriding. Unmarked subprograms are new
+declarations, and may not override another routine.
 
 !wording
 
@@ -97,38 +97,41 @@
 
 pragma Explicit_Overriding;
 
-The form of a pragma Overrides is as follows:
+The form of a pragma Overriding is as follows:
 
-pragma Overrides [(designator)];
+pragma Overriding [(designator)];
 
-The form of a pragma Might_Override is as follows:
+The form of a pragma Optional_Overriding is as follows:
 
-pragma Might_Override [(designator)];
+pragma Optional_Overriding [(designator)];
 
 Add to 8.3 after paragraph 26:
 
 Pragma Explicit_Overriding is a configuration pragma.
 
-Pragmas Overrides and Might_Override shall immediately follow (except
+Pragmas Overriding and Optional_Overriding shall immediately follow (except
 for other pragmas) the declaration for a primitive operation. The optional
-designator of a pragma Overrides or Might_Override shall be the same as the
-designator of the operation which it follows. Only one of pragmas Overrides
-and Might_Override shall be given for a single primitive operation.
-
-A primitive operation to which pragma Overrides applies shall override another
-operation. This rule is not enforced at the compile time of a
-generic_declaration. In addition to the places where Legality Rules normally
+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
+Overriding and Optional_Overriding shall be given for a single primitive
+operation.
+
+A primitive operation to which pragma Overriding applies shall override another
+operation. In addition to the places where Legality Rules normally
 apply, this rule also applies in the private part of an instance of a generic
 unit.
+
+The configuration pragma Explicit_Overriding applies to all declarations within
+compilation units to which it applies, except that in an instance of a generic
+unit, Explicit_Overriding applies if and only if it applies to generic unit. At
+a declaration where a pragma Explicit_Overriding applies, an explicit
+subprogram_declaration to which neither pragma Overriding or
+Optional_Overriding applies shall not be an overridding declaration. In
+addition to the places where Legality Rules normally apply, this rule also
+applies in the private part of an instance of a generic unit.
 
-For a primitive subprogram inherited in a unit to which a pragma
-Explicit_Overriding applies, an overriding explicit declaration shall be
-a subprogram to which pragma Overrides or Might_Override applies. This rule
-is not enforced at the compile time of a generic_declaration. In addition to
-the places where Legality Rules normally apply, this rule also applies in the
-private part of an instance of a generic unit.
 
-Note:
+AARM Note:
 The overriding required by these rules does not necessarily need to happen
 immediately at the declaration of a primitive operation. It could occur later
 because of a later implicit declaration in the declarative region (see 7.3.1).
@@ -143,9 +146,9 @@
 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); pragma Overrides; -- Error:
-   procedure Finalise (Object : in out Root_Type); pragma Overrides; -- Error:
-        -- Note: British spelling of "Finalize".
+                           Data : in Boolean); pragma Overriding; -- Error:
+   procedure Finalise (Object : in out Root_Type); pragma Overriding; -- Error:
+        -- Note: Alternative spelling of "Finalize".
 end Leaf;
 
 The declarations of Do_Something and Finalise will now cause errors. The
@@ -157,16 +160,20 @@
 when no overriding subprograms are declared. This checking will prevent
 accidental overriding.
 
-We add the third pragma (Might_Override) so that we can handle generic units
-where we cannot tell for sure whether overriding occurs. For instance, a mix-in
-generic does not care whether its operations override existing ones (the user
-of the generic may care, but that cannot be specified as part of the generic).
-Therefore, we provide Might_Override as a "don't care" marker, so that projects
-can still use Explicit_Overriding even if such generics are included.
+We add the third pragma (Optional_Overriding) so that we can handle generic
+units where we cannot tell for sure whether overriding occurs. For instance,
+a mix-in generic does not care whether its operations override existing ones
+(the user of the generic may care, but that cannot be specified as part of
+the generic). Therefore, we provide Optional_Overriding as a "don't care"
+marker, so that projects can still use Explicit_Overriding even if such
+generics are included. The effect of pragma Optional_Overriding can be
+thought of as restoring the Ada 95 rules for overriding for a particular
+declaration.
 
 Requiring the explicit declaration of overriding is used in some other
-programming languages, most notably Eiffel. They also have noticed this
-problem.
+programming languages, most notably Eiffel. Other commonly used languages
+(including Java and C++) also have the same problem, but do not have the
+tradition of safety that Ada has.
 
 This additional checking still could allow an error to occur. The problem
 could still occur if there existed two or more overloaded inherited routines,
@@ -174,7 +181,7 @@
 as it is normally the case that all of the inherited routines with a
 single name are overridden as a group.
 
-We considered adding syntax rather than defining pragma Overrides. Syntax was
+We considered adding syntax rather than defining pragma Overriding. Syntax was
 determined to be too heavyweight a solution for an amendment. One idea
 considered using existing keywords was: subprogram_specification is not new;
 These ideas were not considered satisfactory; it was felt that proper syntax
@@ -185,9 +192,9 @@
 pragmas, it will ignore them, and will accept any legal program (along with
 some that would be illegal if the pragmas were accepted).
 
-The pragmas Overrides and Might_Override were defined so that they apply only
-to the immediately preceding subprogram. This is even true if a designator is
-given, which is different than most other Ada pragmas. This behavior is
+The pragmas Overriding and Optional_Overriding were defined so that they apply
+only to the immediately preceding subprogram. This is even true if a designator
+is given, which is different than most other Ada pragmas. This behavior is
 required for these pragmas, as it is very important that they do not
 automatically apply to all members of a set of overloaded operations with
 a single designator. For instance, consider a tagged type with a constructor
@@ -225,11 +232,11 @@
 package P.C is
     type NT is new T;
     procedure Op (Y : NT);
-    pragma Overrides (Op); -- OK.
+    pragma Overriding (Op); -- OK.
     package Nested is
         type NNT is new T;
-        procedure Op (Y : NNT); -- Illegal (Overrides or
-                                -- Might_Override needs to be given)
+        procedure Op (Y : NNT); -- Illegal (Overriding or
+                                -- Optional_Overriding needs to be given)
     end Nested;
 private
     -- P.C.Op overrides P.Op here (P.Op is inherited here).
@@ -241,14 +248,12 @@
     end Nested;
 end P.C;
 
-Another use for Might_Override exists in this example; it can be used
+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.
 
-The pragmas Overrides and Might_Override are not checked in a
-generic_declaration. We do this because the an operation may not override
-in the generic_definition, but be intended to override in an instance. We
-do not want to force the use of Might_Override in all generics; the checking
-can be useful.
+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.
 
 For instance:
 
@@ -257,21 +262,37 @@
 package Gen is
     type DGT is new GT with private;
     procedure Op (Z : DGT);
-    pragma Overrides (Op); -- OK.
+    pragma Overriding (Op); -- Error: Don't override anything.
 private
     -- ...
 end Gen;
-
-If we enforced these pragmas in generic_declarations, we could not give
-Overrides in this generic, as Op does not override anything in the
-generic_declaration or formal part. However, this pragma can be useful, as
-it forces all actual types for GT to have an operation Op. For example,
-using the types from the preceding example:
-
-    package Inst1 is new Gen (P.C.NT); -- OK, P.C.Op is overridden by Gen.Op.
-    package Inst2 is new Gen (P.T); -- Illegal, P.Op is not visible in Inst2,
-                                    -- and does not override.
 
+If we didn't enforce these pragmas in generic_declarations, we could give
+Overriding in this generic. The effect would be to force all actual types for
+GT to have an operation Op. This would effectively modify the contract of
+the generic to include that operation.
+
+An effect of enforcing the pragmas in a generic_declaration is that
+pragma Overriding can never be used on operations of a derivation of a
+generic formal private type (as in the example), as no primitive
+operations are inherited from the formal type. This is not too serious, as
+pragma Optional_Overriding can always be used to allow overriding.
+
+Note that the only check required at instantiation is to recheck operations
+which have neither pragma Overriding nor pragma Optional_Overriding to insure
+that they do not override some inherited operation. The check in the
+generic_declaration is sufficient for pragma Overriding, while pragma
+Optional_Overriding needs no check at all.
+
+The configuration pragma Explicit_Overriding does not necessarily apply to the
+entire partition. It can be given in front of individual units in order to
+apply only to those units. This allows subsystems which take advantage of the
+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
+checked based on whether pragma Explicit_Overriding applies to the generic
+unit, and not whether it applies to the instantiation.
 
 !appendix
 
@@ -313,5 +334,51 @@
 private
     -- Overrides here P.
 end P.C;
+
+*************************************************************
+
+!from Randy Brukardt 12-07-00
+
+Following are my notes on this AI from the Columbia ARG meeting (Nov. 2000).
+All of these changes have been made to the AI.
+
+----
+
+Eiffel: Uses redefines; Java & C++ have the problem.
+
+Change name Overrides to Overriding; Change name Might_Overrides to
+Optional_Overriding.
+
+Delete: "This rule is not enforced at the compile time of a
+generic_declaration." 6-1-3. Two occurrences.
+
+The intent is that the rules are checked both in the template and in the
+instance. (The instance is only necessary for subprograms that do not have an
+pragma Overriding or Optional_Overriding.)
+
+Tuck's implementation model: Each subprogram has a flag (Over, Might, Not),
+which defaults to Might unless the configuration is set (then it defaults to
+Not). Instantiation rechecks. (But it does not recheck whether the configuration
+pragma is in use).
+
+Change wording:
+
+The configuration pragma Explicit_Overriding applies to all declarations within
+compilation units to which it applies, except that in an instance of a generic
+unit, Explicit_Overriding applies if and only if it applies to generic unit. At
+a declaration where a pragma Explicit_Overriding applies, an explicit
+subprogram_declaration to which neither pragma Overriding or Optional_Overriding
+applies shall not be an overridding declaration. In addition to the places where
+Legality Rules normally apply, this rule also applies in the private part of an
+instance of a generic unit.
+
+Note probably ought to be AARM only.
+
+Change "British spelling" to "alternative spelling". (Two places)
+
+Proposal:
+
+In all of these cases, [the Ada compiler is being actively harmful to the
+programmer, ]violat{ed}[ing] the Ada design principle[s] of least surprise. (Introduction, paragraph 8).
 
 *************************************************************

Questions? Ask the ACAA Technical Agent