CVS difference for ais/ai-10218.txt

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

--- ais/ai-10218.txt	2002/10/01 03:08:54	1.1
+++ ais/ai-10218.txt	2003/01/16 01:28:22	1.2
@@ -1,4 +1,4 @@
-!standard 8.3(26)                                    02-09-30  AI95-00218-02/01
+!standard 8.3(26)                                    03-01-15  AI95-00218-02/02
 !class amendment 00-09-30
 !status work item 02-09-30
 !status received 02-09-30
@@ -83,15 +83,20 @@
 which applies only when the programmer asks for it.
 
 Thus, we introduce a new pragma, Explicit_Overriding, and additional syntax
-with new nonreserved keywords which indicate that overiding will or might
+with new nonreserved keywords which indicate that overriding will or might
 occur. Explicit_Overriding is a configuration pragma which requires use of
 the alternative syntax.
 
-Declarations that are overriding are concluded with "overrides;" whereas
-those that might or might not be overriding (this situation can occur with
-generics) are concluded with "maybe overrides;" Subprogram declarations
-without this new syntax and to which pragma Explicit_Overriding applies are
-new declarations and must not override another routine.
+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.
 
 !wording
 
@@ -108,6 +113,16 @@
 abstract_subprogram_declaration ::=
     subprogram specification [overriding_indicator] is abstract;
 
+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
+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
+the visible part; the redeclaration may include an overriding indicator.
+
 Add to 8.3 after paragraph 26:
 
 The form of a pragma Explicit_Overriding is as follows:
@@ -116,30 +131,39 @@
 
 Pragma Explicit_Overriding is a configuration pragma.
 
-
-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 the generic
-unit. At a place where a pragma Explicit_Overriding applies, an explicit
-subprogram_declaration, abstract_subprogram_declaration or generic_instantiation
-of a subprogram without an overriding_indicator shall not be an
-overriding declaration whereas such a subprogram declaration with the
+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.
 
+Change the syntax in 8.5.4 to read
+
+subprogram_renaming_declaration ::= subprogram_specification
+                     [overriding_indicator] renames callable_entity_name;
 
 Change the syntax in 12.3 to read
 
 generic_instantiation ::=
      package defining_program_unit_name is
         new generic_package_name [generic_actual_part];
-   | procedure defining_program_unit_name is
-        new generic_procedure_name [generic_actual_part]
-           [overriding_indicator];
-   | function defining_designator is
-        new generic_function_name [generic_actual_part]
-           [overriding_indicator];
+   | procedure defining_program_unit_name [overriding_indicator] is
+        new generic_procedure_name [generic_actual_part];
+   | function defining_designator [overriding_indicator] is
+        new generic_function_name [generic_actual_part];
 
 AARM Note:
 The overriding required by these rules does not necessarily need to happen
@@ -182,17 +206,23 @@
 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 renaming, generic subprogram declarations,
-formal subprogram parameters and subprogram body stubs. However, we do want
-them to apply to abstract subprograms 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;
 
-One consequence is that we cannot use these forms with a subprogram body given
-alone but must supply a distinct subprogram declaration if we need to use them.
+   procedure Pop(Y: TT) maybe overrides renames Pip;
 
+   procedure Pup overrides is new Pap(P1 => A1, P2 => A2);
+
+One consequence is that we cannot use an overriding indicator with a
+subprogram body given alone but must supply a distinct subprogram
+declaration if we need to include one.
+
 Requiring the explicit declaration of overriding is used in some other
 programming languages, most notably Eiffel (which uses the keyword redefine).
 Other commonly used languages (including Java and C++) also have the same
@@ -275,6 +305,53 @@
 generic_declaration is sufficient for "overrides", while "maybe overrides"
 needs no check at all.
 
+A similar situation arises with private types. Thus consider
+
+package P is
+   type T is private;
+   function "+" (Left, Right: T) return T;
+private
+   type T is range 0 .. 100;     -- "+" overrides
+end P;
+
+as opposed to
+
+package P is
+   type T is private;
+   function "+" (Left, Right: T) return T;
+private
+   type T is new TT;            -- "+" does not override
+end P;
+
+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
+
+package P is
+   type T is private;
+   function "+" (Left, Right: T) return T;
+private
+   type T is range 0 .. 100;
+   function "+" (Left, Right: T) return T overrides;
+end P;
+
+Another similar example is
+
+package P is
+   type T is new T1;
+   procedure Foo;
+private
+   type T is new T2;
+   procedure Foo overrides;
+end P;
+
+This covers the situation where T1 does not have the operation Foo but T2 does.
+
 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
@@ -307,6 +384,20 @@
    procedure Op(X: T) is overriding is abstract;
 
 The double use of is was considered ugly.
+
+We also considered placing the overriding indicator at the beginning thus
+
+   overriding
+   procedure Op(X: T) is abstract;
+
+and at the end
+
+   procedure Pup is new Pap(P1 => A1, P2 => A2) maybe overrides;
+
+Placing the indicator at the beginning was felt to upset the layout.
+Placing the indicator at the end makes it a long way away from the
+designator to which it applies in the case of a generic instantiation
+ - remember that the actual parameter list could be several pages long.
 
 The keyword "overrides" seems natural but "maybe overrides" is perhaps unusual
 and introduces the keyword "maybe". Other possibilities are "perhaps overrides",

Questions? Ask the ACAA Technical Agent