CVS difference for ais/ai-10218.txt

Differences between 1.2 and version 1.3
Log of other versions for file ais/ai-10218.txt

--- ais/ai-10218.txt	2003/01/16 01:28:22	1.2
+++ ais/ai-10218.txt	2003/01/23 03:23:49	1.3
@@ -1,4 +1,4 @@
-!standard 8.3(26)                                    03-01-15  AI95-00218-02/02
+!standard 8.3(26)                                    03-01-21  AI95-00218-02/03
 !class amendment 00-09-30
 !status work item 02-09-30
 !status received 02-09-30
@@ -87,16 +87,18 @@
 occur. Explicit_Overriding is a configuration pragma which requires use of
 the alternative syntax.
 
-Declarations that are overriding include "overrides" whereas those that might
-or might not be overriding (this situation can occur with generics) include
-"maybe overrides". Subprogram declarations (other than those for visible
-operations of a private type) without this new syntax and to which pragma
-Explicit_Overriding applies are new declarations and must not override another
-routine. The same applies to renamings and generic instantiations.
-
-In the case of a subprogram which is a visible operation of a private type,
-it is permitted to redeclare the subprogram in the private part in which
-case the rules for overriding apply to this redeclaration.
+Declarations that are overriding include "overrides" whereas those that
+might or might not be overriding (this situation can occur with generics
+and private types) include "maybe overrides". Subprogram declarations
+(other than those for visible operations of a private type) without this
+new syntax and to which pragma Explicit_Overriding applies are new
+declarations and must not override another routine. The same applies to
+renamings and generic instantiations.
+
+In the case of a subprogram which is a visible operation of a private type
+and which is marked "maybe overriding", it is permitted to redeclare the
+subprogram in the private part with an overriding indicator as necessary
+so that the checking can be performed when the full type is known.
 
 !wording
 
@@ -115,9 +117,10 @@
 
 Add to 8.3 after paragraph 23:
 
-In the case of an explicit declaration of a visible operation of a private
-type by a subprogram declaration, abstract subprogram declaration, subprogram
-renaming declaration or generic instantiation, it is permitted to redeclare
+If an explicit declaration of a visible operation of a private type by
+a subprogram declaration, abstract subprogram declaration, subprogram
+renaming declaration or generic instantiation includes the overriding
+indicator "maybe overrides" then it is permitted to redeclare
 the operation in the corresponding private part by a subprogram declaration.
 Such a redeclaration shall occur following the corresponding
 full_type_declaration and shall be fully conformant with the declaration in
@@ -132,23 +135,18 @@
 Pragma Explicit_Overriding is a configuration pragma.
 
 The configuration pragma Explicit_Overriding applies to all
-explicit subprogram_declarations, abstract_subprogram_declarations,
-subprogram_renaming_declarations or generic_instantiations
-of a subprogram 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 the generic unit.
-      * it does not apply in the visible part of a package to the
-        declarations of operations of a private type declared in
-        that visible part; such declarations shall not include an
-        overriding indicator.
-
-For those declarations to which a pragma Explicit_Overriding applies,
-a declaration without an overriding_indicator shall not be an
-overriding declaration whereas a declaration with the
-overriding_indicator "overrides" shall be an overriding 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.
+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 the generic unit.
+
+At a place where a pragma Explicit_Overriding applies, an explicit
+subprogram_declaration, abstract_subprogram_declaration,
+subprogram_renaming_declaration or generic_instantiation of a subprogram
+without an overriding_indicator shall not be an overriding declaration whereas
+such a subprogram declaration with the overriding_indicator "overrides" shall
+be an overriding 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.
 
 Change the syntax in 8.5.4 to read
 
@@ -196,22 +194,22 @@
 subprograms are declared. This checking prevents accidental overriding.
 
 The form "maybe overrides" is required 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 "maybe overrides" as a "don't care"
-marker, so that projects can still use the pragma Explicit_Overriding even if
-such generics are included. The effect of "maybe overrides" can be
-thought of as restoring the Ada 95 rules for overriding for a particular
-declaration.
+units and operations of private types 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 "maybe overrides" as a "don't care" marker, so that
+projects can still use the pragma Explicit_Overriding even if such generics
+are included. The effect of "maybe overrides" can be thought of as
+restoring the Ada 95 rules for overriding for a particular declaration.
 
 Note that the forms "overrides" and "maybe overrides" are part of a
-subprogram declaration and not the subprogram specification. This is because we
-do not want them to be permitted in all syntactic situations which use
-subprogram specification such as generic subprogram declarations, formal
-subprogram parameters and subprogram body stubs. However, we do want them to
-apply to abstract subprograms, to renaming and to generic instantiations. For
-example
+subprogram declaration and not the subprogram specification. This is because
+we do not want them to be permitted in all syntactic situations which use
+subprogram specification such as generic subprogram declarations,
+formal subprogram parameters and subprogram body stubs. However, we do want
+them to apply to abstract subprograms, to renaming and to generic
+instantiations. For example
 
    procedure Op(X: T) overrides is abstract;
 
@@ -325,26 +323,27 @@
 
 The point is that the partial view does not reveal whether overriding
 occurs or not - nor should it since either implementation ought to be
-acceptable. One possibility would be to put "maybe overrides" on the
-declaration of "+" but this removes all the possibility of checking.
-The solution chosen is to forbid an overriding indicator in the
-declaration in the visible part and to permit a redeclaration of the
-operation in the private part with an overriding indicator if necessary.
-Thus
+acceptable. We can therefore put "maybe overrides" on the declaration of
+"+" so that either implementation is possible. In order to permit checking when
+the full circumstances are known, we introduce the possibility of a
+redeclaration of the operation in the private part. The redeclaration may
+include an overriding indicator and is checked as appropriate. A redeclaration
+is only permitted when that in the visible part has the overriding indicator
+"maybe overrides" and naturally has to be fully conformant with it. Thus
 
 package P is
    type T is private;
-   function "+" (Left, Right: T) return T;
+   function "+" (Left, Right: T) return T maybe overrides; -- don't know here
 private
    type T is range 0 .. 100;
-   function "+" (Left, Right: T) return T overrides;
+   function "+" (Left, Right: T) return T overrides;  -- now we know
 end P;
 
 Another similar example is
 
 package P is
    type T is new T1;
-   procedure Foo;
+   procedure Foo maybe overrides;
 private
    type T is new T2;
    procedure Foo overrides;

Questions? Ask the ACAA Technical Agent