I posted this a few weeks ago but nobody responded.
IMO, the 12/96 DWP is vaguely specifying incorrect
handling of ambiguous overloads of several built-in
operators.  Am I seeing this wrongly?  Or is the
wording extracted below in need of correction?

In the December 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 opera-
  tor  ->, 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.

--
-- Larry Brasfield
The aforementioned views are mine alone.
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]