CVS difference for ais/ai-00310.txt

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

--- ais/ai-00310.txt	2003/03/04 04:56:23	1.3
+++ ais/ai-00310.txt	2003/05/24 00:51:42	1.4
@@ -1,4 +1,4 @@
-!standard 6.4(08)                                      03-02-19  AI95-00310/03
+!standard 6.4(08)                                      03-05-22  AI95-00310/04
 !class amendment 02-09-30
 !status Amendment 200Y 03-02-19
 !status ARG Approved 5-0-3  03-02-08
@@ -13,7 +13,7 @@
 
 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.
+nondispatching subprograms are not considered for overload resolution.
 Declaring an abstract override for an inherited operation effectively has the
 effect of "undefining" this operation.
 
@@ -21,7 +21,7 @@
 
 Consider the following program:
 
-with Text_Io; use Text_Io;
+with Text_IO; use Text_IO;
 procedure Proc is
    package Pack is
       type Unit is new Float;
@@ -47,9 +47,9 @@
 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
+To the human reader, the call at (3) appears to be unambiguous, 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
+the declaration at (1) is considered a possible interpretation for overload
 resolution, making the call ambiguous.
 
 !proposal
@@ -68,16 +68,16 @@
 !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
+in overload resolution. It can be argued that stating explicitly 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.
+automatic overload 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
+In the case of an abstract subprogram (at least for the untagged 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!".
@@ -94,13 +94,13 @@
 
 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.
+complexity to the existing overload 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.
+overload 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
@@ -116,7 +116,7 @@
 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
+dispatching operations from being even considered by the overload
 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
@@ -125,7 +125,7 @@
 Note that 3.9.3(7) is still useful to reject non-dispatching calls to abstract
 dispatching operations.
 
-!examples
+!example
 
 (See problem.)
 

Questions? Ask the ACAA Technical Agent