The number of implicit conversions in overloading resolution AI00606/03 1
891119 ra WI
 !standard 04.06 (15) 891119 AI00606/03
!class ramification 890515 (provisional classification)
!status workitem 890515
!status received 881213
!references AI00136
!topic The number of implicit conversions in overloading resolution
!summary 890515 (DRAFT)
The number of required implicit conversions is not considered when resolving
an overloaded expression.
!question 890515 (DRAFT)
Consider the following example:
procedure P (X : INTEGER; Y : BOOLEAN; Z : BOOLEAN) is ... end P;
procedure P (X : BOOLEAN; Y : INTEGER; Z : INTEGER) is ... end P;
function "<" (X, Y : INTEGER) return INTEGER is ... end "<";
...
P(5 < 4, 6 < 7, 1 < 2);  is P resolvable? (no)
There are two possible arguments for deciding whether the call can be
resolved:
1) An interpretation using the first P requires only two
implicit conversions (the conversion of 5 and 4 to type
INTEGER) whereas an interpretation using the second P
requires four implicit conversions (two for each of the last
two parameters in the call). Since the call to the first P
requires fewer implicit conversions, P is resolved to mean
the first P.
2) Using the reasoning given for AI00136, for the first two
implicit conversions, there is another legal interpretation
without these conversions, so no conversions can be applied
and the call is unresolvable.
Is the call resolvable or not?
!response 890515 (DRAFT)
AI00136 says:
An implicit conversion of a convertible universal operand is
applied if and only if the innermost enclosing complete context
(see 8.7) determines a unique numeric target type for the
implicit conversion, and there is no legal interpretation of this
context without this conversion.
Although the ACVC Implementer's Guide (December 1986) says that the call of P
can be resolved because one interpretation requires fewer implicit
conversions than another, there is no basis for this conclusion. As the
DRAFT DRAFT DRAFT
The number of implicit conversions in overloading resolution AI00606/03 2
891119 ra WI
response in AI00136 notes, for each of the implicit conversions, it is the
case that there is another legal intepretation of the complete context
without "this conversion." Therefore, no implicit conversion can be applied,
and the call is illegal.
 !appendix 890704
*****************************************************************************
!section 04.06 (15) Keith Enevoldsen/Boeing 881122 8301044
!version 1983
!topic Implicit conversion rules
!references AI00136, AIG(86)8.7.a.7
If there are multiple legal interpretations of a construct, but one
intepretation involves fewer implicit conversions than the others,
is overloading always resolved to that interpretation?
The ACVC Implementers' Guide (version 1, Dec 86) 8.7.a.7 says
that such a counting scheme should be used:
S3: "... it is necessary to keep track of how many implicit
conversions have been performed ..."
S4: "... since one of the operators requires more implicit
conversions ..."
S7: "... since this result type is obtained with fewer implicit
conversions ..."
S8: "Since ... requires fewer implicit conversions in its subtree ..."
AI00136 has 3 examples, all of which would be correctly handled
simply by counting the number of implicit conversions for each
interpretation and choosing the one with the fewest implicit
conversions if there is only one.
But, consider this example:
 Example 4
procedure P (X : INTEGER; Y : BOOLEAN; Z : BOOLEAN) is ... end P;
procedure P (X : BOOLEAN; Y : INTEGER; Z : INTEGER) is ... end P;
function "<" (X, Y : INTEGER) return INTEGER is ... end "<";
...
P(5 < 4, 6 < 7, 1 < 2);  is overloading resolvable?
There are two possible interpretations of P(5 < 4, 6 < 7, 1 < 2).
Consider these two methods of overload resolution:
1. A "counting" scheme would resolve to the first P because the
interpretation using the first P involves 2 implicit conversion
whereas the interpretation using the second P involves 4 implicit
conversions.
DRAFT DRAFT DRAFT
The number of implicit conversions in overloading resolution AI00606/03 3
891119 ra WI
2. Using the reasoning given for AI00136 examples 1 through 3:
for each implicit conversion, there is another legal interpretation
without "this conversion," so no conversions may be applied and
the construct is unresolvable.
Which method is correct?
*****************************************************************************
!section 04.06 (15) Ron Brender 890605 8301293
!version 1983
!topic The number of implicit conversions
!reference AI00606/01
I support the conclusion of this AI. The "algorithm" presented in the
IG always struck me as wrong from "day zero". This is reflected in
the following comment on the IG submitted back in 1984:
Section 08.07.a.07(S3S12) Ron Brender 840104
Version G1
Topic "more or less" implicit conversions
The use of a count of the number of implicit conversions in the
model given here seems illadvised. The ARM certainly says
nothing about "minimizing" the number of implicit conversions 
it only states conditions under which a particular implicit
conversion is applied or not. Adopting a model that counts the
number of implicit conversions invites concern about cases where
there may be a choice of implicit conversions  cases which can
be shown to be just not possible (the argument is lengthly and
will not be dealt with here).
[Ed. In light of the question in this AI, perhaps the argument
was too lengthly to be correct...]
It appears that the appeal to a count is motivated solely by the
examples involving **. But we know that the right operand of **
can never be of a universal type: the predefined ** operators all
require INTEGER and any userdefined overloading of ** must have a
nonuniversal type in its specification. It follows that in any
syntactic occurance of the ** operator (whether infix or call
notation) any implicit conversions that MIGHT be applied to
satisfy the required type of the right operand in fact MUST be
applied. Consequently, the presence (never absence) of an
implicit conversion in the right operand cannot make any
difference in the resolution of any larger complete context.
Having disposed of the need to take account of implicit
conversions in the right operand of **, there appears to be no
need to have a count as such for the purposes of the remaining
part of the model  it suffices to replace the current use of the
DRAFT DRAFT DRAFT
The number of implicit conversions in overloading resolution AI00606/03 4
891119 ra WI
count with a simple bit indicating whether or not an
interpretation involves any implicit conversion (other than in the
right operand of **). I think everything else goes through
without further difficulty.
 *****************************************************************************

 !section 04.06 (15) Hans Hurvig 890704 8301321
 !version 1983
 !topic Implicit conversion rules

 !reference AI00606/01

 I agree with the conclusion of AI00606. However, Ron Brender's
 comments (which were circulated at the ARG meeting in Madrid)
 contain what I believe to be a mistaken conclusion, and since the
 area is still surrounded by some confusion I offer the
 following analysis.

 The rule should be understood in terms of "conversion sets":
 the set of (convertible) operands which in a given resolution
 undergo implicit conversion.

 Now, 4.6(15) says that if a conflict arises, you choose the
 resolution (if any) whose conversion set is a proper subset of
 the conversion sets of all conflicting resolutions.

 The countapproach (representing just the cardinality of the
 sets) and the bitapproach (representing just whether the sets
 are empty) are attempts to avoid having to represent the sets
 in their entirety.

 The countapproach is invalidated by the example in AI00606.

 The bitapproach cannot be repaired by making special cases for
 the "**" operator. Similar cases (as well as more complicated
 ones) can be constructed without "**":

 function "<" ( L,R: INTEGER ) return INTEGER;

 function F ( L: BOOLEAN; R: INTEGER ) return BOOLEAN; F1
 function F ( L: INTEGER; R: INTEGER ) return INTEGER;

 Now the call F(3<4,5) gives rise to two nonconflicting
 resolutions which both contain conversions (of the right
 operand), but where further analysis is still allowed to
 select F1 if needed:

 procedure P ( X: BOOLEAN ); P1
 procedure P ( X: INTEGER );
 ...
 P ( F(3<4,5) ); legal, calls F1 and P1, only 5 converted
DRAFT DRAFT DRAFT
The number of implicit conversions in overloading resolution AI00606/03 5
891119 ra WI
 Note however, that the countapproach is sufficient to
 identify the potential survivor among the conflicting
 resolutions: lower cardinality is a necessary, though not
 sufficient, condition for being a proper subset.

 Finally, on a more pedantic note, the formulation of 4.06(15) is
 unfortunate because it is so indirect: it specifies what must be
 satisfied, not how to find it. This gives some problems with
 circularity, where the legality of X is defined in terms of the
 legality of Y, whose legality may be defined in terms of the
 legality of X. This actually happens if you look very closely at
 the example in AI00606, but of course the (pragmatic!) solution
 is that both are illegal.
DRAFT DRAFT DRAFT