[This is a very slightly edited copy of another thread -- this time
marked as a defect report.]

 [Moderator's note: this defect report has been
 forwarded to the C++ committee. -moderator(fjh).]

Hello,

This is closely related to core issue #260
<http://anubis.dkuug.dk/JTC1/SC22/WG21/docs/cwg_active.html#260>
but is not resolved by the suggested resolution there.

Given:

struct T {
     operator int() const;
     operator double() const;
};

I believe the standard requires the following assignment to be
ambiguous (even though I expect that would surprise the user):

double x;
void f(const T& t) { x = t; }

The problem is that both of these built-in operator=()s exist (13.6/18
[over.built]):
         double& operator=(double&, int);
         double& operator=(double&, double);

Both are an exact match on the first argument and a user conversion on
the second.  There is no rule that says one is a better match than the
other.

The compilers that I have tried (even in their strictest setting) do
not give a peep.  I think they are not following the standard.  They
pick double& operator=(double&, double) and use T::operator double()
const.

I hesitate to suggest changes to overload resolution, but a possible
resolution might be to introduce a rule that, for built-in operator=
only, also considers the conversion sequence from the second to the
first type.  This would also resolve core issue #260.

It would still leave 'x += t' etc. ambiguous -- which might be the
desired behavior and is the current behavior of some compilers.
---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]