CVS difference for ais/ai-00310.txt

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

--- ais/ai-00310.txt	2003/01/15 00:59:06	1.2
+++ ais/ai-00310.txt	2003/03/04 04:56:23	1.3
@@ -1,5 +1,7 @@
-!standard 3.9.3 (07)                                   03-01-08  AI95-00310/02
+!standard 6.4(08)                                      03-02-19  AI95-00310/03
 !class amendment 02-09-30
+!status Amendment 200Y 03-02-19
+!status ARG Approved 5-0-3  03-02-08
 !status work item 02-09-30
 !status received 02-09-04
 !priority Medium
@@ -50,23 +52,18 @@
 the declaration at (1) is considered a possible interpretation for overloading
 resolution, making the call ambiguous.
 
-Making 3.9.3(7) an overloading rule would provide the expected behavior. There
-is no upward compatibility issue, since it would simply make illegal Ada95
-programs legal.
-
 !proposal
 
 (See wording.)
 
 !wording
 
-Modify 6.4(8) as follows:
+Add "The name or prefix shall not resolve to denote an abstract
+subprogram unless it is also a dispatching subprogram." to 6.4(8).
 
-The name or prefix given in a procedure_call_statement shall resolve to denote
-a callable entity that is a {nonabstract or dispatching} procedure, or an
-entry renamed as (viewed as) a procedure. The name or prefix given in a
-function_call shall resolve to denote a callable entity that is a {nonabstract
-or dispatching} function.
+Add an AARM note:
+This rule is talking about dispatching operations (which is a
+static concept) and not about dispatching calls (which is a dynamic concept).
 
 !discussion
 
@@ -112,8 +109,13 @@
 full view would have to be abstract, and that's illegal if the partial view is
 untagged.
 
-Rather than making 3.9.3(7) a Name Resolution Rule (as suggested by
-the !question), it seems simpler to change 6.4(8) to prevent abstract non-
+The 'obvious' change of making 3.9.3(7) a Name Resolution Rule would be
+impossible to implement, because it is impossible to tell if a call is a
+dispatching call until after it has been resolved. In order to do this,
+3.9.3(7) would have to be split into a pair of similar rules (one covering
+dispatching operations and the other covering dispatching calls).
+
+Therefore, it seems simpler to change 6.4(8) to prevent abstract non-
 dispatching operations from being even considered by the overloading
 resolution algorithm. This is likely to have a relatively limited impact on
 implementations, as such subprograms can be filtered out early in the
@@ -127,6 +129,26 @@
 
 (See problem.)
 
+!corrigendum 6.4(8)
+
+@drepl
+The @fa<name> or @fa<prefix> given in a @fa<procedure_call_statement> shall
+resolve to denote a callable entity that is a procedure, or an entry renamed as
+(viewed as) a procedure. The @fa<name> or @fa<prefix> given in a
+@fa<function_call> shall resolve to denote a callable entity that is a
+function. When there is an @fa<actual_parameter_part>, the prefix can be an
+@fa<implicit_dereference> of an access-to-subprogram value.
+@dby
+The @fa<name> or @fa<prefix> given in a @fa<procedure_call_statement> shall
+resolve to denote a callable entity that is a procedure, or an entry renamed as
+(viewed as) a procedure. The @fa<name> or @fa<prefix> given in a
+@fa<function_call> shall resolve to denote a callable entity that is a
+function. The @fa<name> or @fa<prefix> shall not resolve to denote an abstract
+subprogram unless it is also a dispatching subprogram. When there is an
+@fa<actual_parameter_part>, the prefix can be an @fa<implicit_dereference>
+of an access-to-subprogram value.
+
+
 !ACATS Test
 
 A C-Test similar to the example should be created.
@@ -312,6 +334,41 @@
 a) the behavior of abstract is exactly right and desirable
 
 b) JPR's proposal would damage the safety of the language
+
+****************************************************************
+
+From: Randy Brukardt
+
+The minutes of Meeting 18 say to replace the wording by:
+
+"The name or prefix shall not resolve to denote an abstract nondispatching
+subprogram."
+
+I didn't use this, because "nondispatching subprogram" is not a term
+defined in the Standard.
+
+The Standard indexes "nondispatching call", but there is no definition (or use!)
+of the term where it's indexed. And there is no index entry for "nondispatching
+operation". So, neither of these concepts is defined. Moreover,
+"nondispatching call" is never used in normative text, and "nondispatching
+operation" and "nondispatching subprogram" are never used at all.
+
+It's not clear to me that "nondispatching" is automatically the reverse of
+"dispatching". This isn't a case of typical English usage, and the lack of a
+hyphen makes it look like a different word.
+
+I tried:
+The name or prefix shall resolve to denote an non-abstract or dispatching
+subprogram.
+(which is closer to the original proposed wording), but this uses the
+undefined term "non-abstract". This looks a bit more like an inverse, because
+of the hyphen. But this too is not defined by the standard, and it is used only
+in one RM note, and various AARM annotations.
+
+So I settled on:
+
+The name or prefix shall not resolve to denote an abstract subprogram unless it
+is also a dispatching subprogram.
 
 ****************************************************************
 

Questions? Ask the ACAA Technical Agent