In the November 1996 draft C++ standard, in section 13 Overloading,
the following text can be found at 13.3.1.2.9:
  13.3.1.2  Operators in expressions
[over.match.oper]
. . .
9 If the operator is the operator ,, the unary operator &, or the
  operator  ->, and overload resolution is unsuccessful, then the
  operator is assumed to be the  built-in  operator  and  interpreted
  according  to clause _expr_.

As I read the above, I wonder if "unsuccessful" is what was meant.
Earlier, (at 13.3.4) the phrase "overload resolution succeeds" is
said to occur when a best viable overload exists and is unique,
(resulting from finding the best viable overload on each argument).

This seems to defeat the purpose of generally making ambiguity an
error in C++.  Under the usual regime, where ambiguity is an error,
if I add an overload that creates an (unintended!) potential ambiguity,

and I use it in a way that creates an actual ambiguity, the result is
an error and I have to decide what I really meant to occur.  But with
the above rule, where the overload reverts to the built-in operator
upon "unsuccess", which can result from adding an overload that
gives rise to an ambiguity, I can get a silent change in behavior
due to the ambiguity.

I suggest that the phrase "and overload resolution is unsuccessful"
of section 13.3.1.2.9 should be "and no viable overloads can be
found for the operator".  At the very least, the meaning of the word
"succeeds" in this context needs to be qualified.

BTW, Could someone post the e-mail address of whoever is
gathering "public comments" on the draft standard?

--
Larry Brasfield

The opinions expressed herein are mine, and are not
intended to reflect the views of any other entity.
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]