Defect Report: unwanted ambiguity with user-defined conversion and built-in operator=

[scott douglass]

[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...@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html ]