CVS difference for ais/ai-00310.txt

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

--- ais/ai-00310.txt	2002/10/01 03:08:54	1.1
+++ ais/ai-00310.txt	2003/01/15 00:59:06	1.2
@@ -1,17 +1,19 @@
-!standard 3.9.3 (07)                                   02-09-30  AI95-00310/01
+!standard 3.9.3 (07)                                   03-01-08  AI95-00310/02
 !class amendment 02-09-30
 !status work item 02-09-30
 !status received 02-09-04
 !priority Medium
 !difficulty Medium
-!subject Make 3.9.3(7) an overloading rule?
+!subject Ignore abstract nondispatching subprograms during overloading
+resolution
 
 !summary
 
-3.9.3(7) forbids calling an abstract subprogram, however this rule is
-not an overloading rule. As a consequence, calls to abstract
-subprograms are considered in overloading resolution, making some
-contexts unnecessarily ambiguous.
+A mechanism is added to make it possible to "undefine" an inherited operation
+for an untagged type. The name resolution rules are changed so that abstract
+nondispatching subprograms are not considered for overloading resolution.
+Declaring an abstract override for an inherited operation effectively has the
+effect of "undefining" this operation.
 
 !problem
 
@@ -39,19 +41,18 @@
    Put_Line (Image (X * X)); -- (3) Ambiguous
 end Proc;
 
-Such structures are frequent in programs that take advantage of Ada's
-strong typing for enforcing physical units consistency. The intent of
-making the "*" at (1) abstract is, in effect, to remove the
-(physically incorrect) operation.
-
-To the human reader, the call at (3) appears to not be ambiguous,
-since the intent is to have only the "*" at (2) available for the type
-Unit. However, the declaration at (1) is considered a possible
-interpretation for overloading resolution, making the call ambiguous.
+Such structures are frequent in programs that take advantage of Ada's strong
+typing for enforcing physical units consistency. The intent of making the "*"
+at (1) abstract is, in effect, to remove the (physically incorrect) operation.
+
+To the human reader, the call at (3) appears to not be ambiguous, since the
+intent is to have only the "*" at (2) available for the type Unit. However,
+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.
+is no upward compatibility issue, since it would simply make illegal Ada95
+programs legal.
 
 !proposal
 
@@ -59,39 +60,68 @@
 
 !wording
 
-Add new sub-heading to 3.9.3 for "Name Resolution Rules", and move 3.9.3(7)
-under that heading.
+Modify 6.4(8) as follows:
 
+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.
+
 !discussion
+
+It is a matter of appreciation how much should be "automatic" vs. "explicit"
+in overloading resolution. It can be argued that stating explicitely which
+subprogram to call is always safer than letting the compiler decide. However,
+this line of reasoning would lead to concluding that there should be *no*
+automatic overloading resolution at all.
+
+In practice, risk should be balanced with usefulness. As a rule of thumb,
+"automatic" resolution can be allowed if there is no uncertainty about the
+programmer's intent.
+
+In the case of an abstract subprogram (at least for the non-tagged case), the
+intent of the programmer is clearly to make the subprogram "unavailable". It
+seems odd to force the programmer to state: "don't worry, the subprogram that
+I want to call is not the one that does not exist!".
+
+The only case where the current rule would catch an error and not the new one
+is if:
+1) The programmer incorrectly wants to call an abstract subprogram, and
+2) There is another interpretation that happens to be there, but not the one
+the programmer wants.
+
+This case seems much less likely than other cases where the "wrong" subprogram
+is called, like for example, having two packages declaring subprograms with
+the same profile, and having a use clause for the wrong package.
+
+While there is some sympathy for using abstract subprograms as a mechanism for
+"undefining" an inherited operation, we must be cautious to avoid adding more
+complexity to the existing overloading resolution rules.
+
+Clearly, abstract subprograms must remain candidates for overload resolution
+if there is a possibility that they be dispatching operations, so we must not
+make any change for tagged types. The new rule has to cause abstract
+subprograms which are not dispatching operations to be ignored by the
+overloading resolution algorithm.
+
+The case of private types deserves special consideration. It is possible for
+an untagged private type to have a tagged completion. If such a type could
+have an abstract primitive subprogram, the new rule would violate the privacy
+of private types. But in order to have an abstract primitive operation, the
+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-
+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
+resolution process (typically at the time when functions or procedures are
+filtered out to implement the rest of 6.4(8)).
 
-It is a matter of appreciation how much should be "automatic"
-vs. "explicit" in overloading resolution. It can be argued that
-stating explicitely which subprogram to call is always safer than
-letting the compiler decide. However, this line of reasoning would
-lead to concluding that there should be *no* automatic overloading
-resolution at all.
-
-In practice, risk should be balanced with usefulness. As a rule of
-thumb, "automatic" resolution can be allowed if there is no
-uncertainty about the programmer's intent.
-
-In the case of an abstract subprogram (at least for the non-tagged
-case), the intent of the programmer is clearly to make the subprogram
-"unavailable". It seems odd to force the programmer to state: "don't
-worry, the subprogram that I want to call is not the one that does not
-exist!".
-
-The only case where the current rule would catch an error and not the
-new one is if:
-1) The programmer incorrectly wants to call an abstract subprogram,
-and
-2) There is another interpretation that happens to be there, but not
-the one the programmer wants.
-
-This case seems much less likely than other cases where the "wrong"
-subprogram is called, like for example, having two packages declaring
-subprograms with the same profile, and having a use clause for the
-wrong package.
+Note that 3.9.3(7) is still useful to reject non-dispatching calls to abstract
+dispatching operations.
 
 !examples
 

Questions? Ask the ACAA Technical Agent