CVS difference for ais/ai-00228.txt

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

--- ais/ai-00228.txt	2000/12/07 04:35:35	1.3
+++ ais/ai-00228.txt	2002/01/24 04:54:11	1.4
@@ -1,5 +1,6 @@
-!standard  3.09.3    (6)                             00-04-10  AI95-00228/00
+!standard  3.09.3    (6)                             02-01-23  AI95-00228/01
 !class binding interpretation 00-04-10
+!status work item 02-01-23
 !status received 00-04-10
 !priority Low
 !difficulty Medium
@@ -8,17 +9,178 @@
 
 !summary
 
+A subprogram which 'shall be overridden' in the sense of 3.9.3(6) is subject
+to the same restrictions as an abstract subprogram.
+
 !question
 
+AI95-00211 states that "the 'shall be overridden' property of 3.9.3(6)  applies
+to a renamed view. Thus, any renaming of an inherited subprogram that must be
+overridden is illegal."
+
+It seems that this formulation is incomplete, and that AI95-00211 should have
+covered some other cases.  Consider the following example, derived from the
+one in the AI:
+
+   package Types is
+       type T is abstract tagged null record;
+       function F return T;
+       generic
+          type NT is new T with private;
+          with function NF return NT;
+       procedure G;
+   end Types;
+
+   with Types;
+   package Extensions is
+       type E is new Types.T with null record;
+       type A is access function return E;
+       X : A := F'Access; -- Legal? (No.)
+       procedure I is new Types.G (E, F); -- Legal? (No.)
+       function F return E;
+   end Extensions;
+
+Hopefully the lines marked "Legal?" are actually illegal, otherwise it would
+be possible to create a reference to or call such a 'shall be overridden'
+subprogram.
+
+These are only some of the constructs that can cause trouble.  Between the
+place where E is declared and the place where F is overridden, it is for
+instance possible to use E as a generic actual parameter (and one wonders if
+the generic is able to call the inherited F) or to derive from E (and one
+wonders if the derived type inherits F, and if the inherited subprogram has
+the 'shall be overridden' property).
+
 !recommendation
 
+(See Wording.)
+
 !wording
 
+Replace 3.9.3(4) by:
+
+For a derived type, if the parent or ancestor type has an abstract or
+insubstantial primitive subprogram, or a primitive function with a controlling
+result, then:
+
+Replace the first sentence of 3.9.3(6) with:
+
+Otherwise, the subprogram is _insubstantial_; an insubstantial subprogram
+shall be overridden with a nonabstract subprogram; [for a type declared in the
+visible part of a package, the overriding may be either in the visible or the
+private part.]
+
+Replace 3.9.3(7) by:
+
+A call on an abstract or insubstantial subprogram shall be a dispatching call;
+[nondispatching calls to an abstract or insubstantial subprogram are not
+allowed.]
+
+Replace the second sentence of 3.9.3(9) with:
+
+If a generic formal type is abstract, then for each primitive subprogram of the
+formal that is neither abstract nor insubstantial, the corresponding primitive
+subprogram of the actual shall neither be abstract nor insubstantial.
+
+Replace 3.9.3(11) by:
+
+A generic actual subprogram shall not be an abstract or insubstantial
+subprogram. The prefix of an attribute_reference for the Access,
+Unchecked_Access, or Address attributes shall not denote an abstract or
+insubstantial subprogram.
+
 !discussion
 
-!corrigendum xx.xx.xx(0x)
+The subprograms which have the 'shall be overridden' property of 3.9.3(6) are
+very similar to abstract subprograms. However, they are not defined as
+abstract. This is quite strange, because it seems that all the rules in 3.9.3
+which have to do with abstract subprograms would be applicable to these
+'shall be overridden' subprograms. This is true in particular of 3.9.3(4),
+3.9.3(7), 3.9.3(9), and 3.9.3(11).
+
+We have two options. Either we change 3.9.3(6) to state that the 'shall be
+overridden' subprograms are actually abstract, and all the rules in 3.9.3 now
+prevent nasty usages of these subprograms. Or we invent a new term to designate
+them, and we complement some of the rules in 3.9.3 to forbid the usages that
+are known to be problematic.
+
+Archeology indicates that in version 4.0 of RM95, the rules of 3.9.3(6) were
+phrased in terms of abstract subprograms, and this was changed in version 5.0
+of RM95. This seems to indicate that the 4.0 formulation was inadequate; this
+is probably because this formulation had the consequence that nonabstract
+tagged types could have abstract subprograms.
+
+So we decide to create new terminology and fix various rules in 3.9.3: the
+subprograms covered by 3.9.3(6) are dubbed "insubstantial", and we change
+some rules to say "abstract or insubstantial".
+
+!corrigendum 3.9.3(4)
+
+@drepl
+For a derived type, if the parent or ancestor type has an abstract
+primitive subprogram, or a primitive function with a controlling result, then:
+@dby
+For a derived type, if the parent or ancestor type has an abstract or
+insubstantial primitive subprogram, or a primitive function with a controlling
+result, then:
+
+!corrigendum 3.9.3(6)
+
+@drepl
+@xbullet<Otherwise, the subprogram shall be overridden with a nonabstract
+subprogram; for a type declared in the visible part of a package, the
+overriding may be either in the visible or the private part. However, if
+the type is a generic formal type, the subprogram need not be overridden
+for the formal type itself; a nonabstract version will necessarily be
+provided by the actual type.>
+@dby
+@xbullet<Otherwise, the subprogram is @i<insubstantial>; an insubstantial
+subprogram shall be overridden with a nonabstract subprogram; for a type
+declared in the visible part of a package, the overriding may be either in
+the visible or the private part. However, if the type is a generic formal type,
+the subprogram need not be overridden for the formal type itself; a nonabstract
+version will necessarily be provided by the actual type.>
+
+!corrigendum 3.9.3(7)
+
+@drepl
+A call on an abstract subprogram shall be a dispatching call;
+nondispatching calls to an abstract subprogram are not allowed.
+@dby
+A call on an abstract or insubstantial subprogram shall be a dispatching call;
+nondispatching calls to an abstract or insubstantial subprogram are not
+allowed.
+
+!corrigendum 3.9.3(9)
+
+@drepl
+If a partial view is not abstract, the corresponding full view shall not
+be abstract. If a generic formal type is abstract, then for each primitive
+subprogram of the formal that is not abstract, the corresponding primitive
+subprogram of the actual shall not be abstract.
+@dby
+If a partial view is not abstract, the corresponding full view shall not
+be abstract. If a generic formal type is abstract, then for each primitive
+subprogram of the formal that is neither abstract nor insubstantial, the
+corresponding primitive subprogram of the actual shall neither be abstract
+nor insubstantial.
+
+!corrigendum 3.9.3(11)
+
+@drepl
+A generic actual subprogram shall not be an abstract subprogram. The
+@fa<prefix> of an @fa<attribute_reference> for the Access, Unchecked_Access,
+or Address attributes shall not denote an abstract subprogram.
+@dby
+A generic actual subprogram shall not be an abstract or insubstantial
+subprogram. The @fa<prefix> of an @fa<attribute_reference> for the Access,
+Unchecked_Access, or Address attributes shall not denote an abstract
+or insubstantial subprogram.
 
 !ACATS test
+
+A B-Test should be created to test these rules, possibly added to an existing
+test.
 
 !appendix
 

Questions? Ask the ACAA Technical Agent