CVS difference for ais/ai-00228.txt

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

--- ais/ai-00228.txt	2005/06/16 23:47:12	1.11
+++ ais/ai-00228.txt	2005/08/21 06:00:14	1.12
@@ -1,4 +1,4 @@
-!standard  3.09.3    (6)                             03-05-03  AI95-00228/05
+!standard  3.09.3    (6)                             05-07-27  AI95-00228/06
 !standard  8.05.4    (5/1)
 !class binding interpretation 03-01-07
 !status Amendment 200Y 03-02-20
@@ -17,6 +17,8 @@
 subject to the restrictions that apply to an abstract subprogram. It is
 illegal to rename a "shall be overridden" subprogram.
 
+It is illegal to rename-as-body an abstract subprogram.
+
 !question
 
 AI95-00211 states that "the 'shall be overridden' property of 3.9.3(6) applies
@@ -44,6 +46,10 @@
 there are a number of constructs that could be used to reference F. Are such
 constructs legal? (Yes.)
 
+Also, it appears that there is no rule preventing renaming-as-body an
+abstract subprogram. But of course an abstract subprogram has no body, so
+that seems silly. Should there be a rule? (Yes.)
+
 !recommendation
 
 (See summary.)
@@ -54,15 +60,18 @@
 
 !discussion
 
-The essence of the question revolves around the difference between "abstract"
-and "shall be overridden". AI95-00211 seems to have been written with the
-assumption that these terms were more or less synonymous, but in fact they are
-not. By definition, an abstract subprogram has no implementation, so we must
-prevent any construct that could lead to nondispatching calls to such a
-subprogram. On the other hand, the rules of 3.9.3(6) ensure that an
-overrider will be provided for each "shall be overridden" subprogram, and that
-this overrider will not be abstract (assuming the type itself is not abstract).
-So nondispatching calls to such subprograms are fine, because we can guarantee
+The answer to the second question is easy: this is an obvious hole, and we
+add the needed rule.
+
+The essence of the first question revolves around the difference between
+"abstract" and "shall be overridden". AI95-00211 seems to have been written
+with the assumption that these terms were more or less synonymous, but in fact
+they are not. By definition, an abstract subprogram has no implementation, so
+we must prevent any construct that could lead to nondispatching calls to such a
+subprogram. On the other hand, the rules of 3.9.3(6) ensure that an overrider
+will be provided for each "shall be overridden" subprogram, and that this
+overrider will not be abstract (assuming the type itself is not abstract). So
+nondispatching calls to such subprograms are fine, because we can guarantee
 that there exists a proper implementation.
 
 To illustrate the difference, consider the following example, which is somewhat
@@ -195,8 +204,11 @@
 is frozen, and the renaming renames the subprogram itself, through one or more
 subprogram renaming declarations, none of whose subprograms has been frozen.
 @dinst
-If the @i<callable_entity_>@fa<name> of a renaming denotes a subprogram which
-shall be overridden (see 3.9.3), then the renaming is illegal.
+The @i<callable_entity_>@fa<name> of a renaming shall not denote a
+subprogram that requires overriding (see 3.9.3).
+
+The @i<callable_entity_name> of a renaming-as-body shall not
+denote an abstract subprogram.
 
 !ACATS test
 

Questions? Ask the ACAA Technical Agent