In article <dillC92xtJ.H5s@netcom.com> dill@twain.notis.com writes:
>     For purposes of argument matching, a nonstatic member function
                                                     ^^^^^^
...
>     extra argument and _no_ _user-defined_ _conversions_ [emphasis

I read that to apply only against conversions from one class to another.
Converting to a built-in type seems to be ok, because the rule is talking
about member functions, not built-in operators.

Thus, it seems to be correct for the compiler to complain about an
ambiguity when the choice is between converting the object to a built-
in type to apply a built-in operator, vs using a member operator
function that needs a conversion for its 2nd argument.

I hope my interpretation is correct, because I recently rewrote part of
my C++ parser to make it work that way.

Here's a tough one on operator overloading.  I'm using the 1990
edition of the ARM, so there's some possibility that the standards
committee has already wrestled with this and resolved it since then.
It's even possible this newsgroup has seen it before (I confess to
not having kept current, though I was an avid reader in 1991).
Anyway, I'm hoping someone can shed light on this.

The paragraph in question is from section 13.2, "argument matching".
In my edition, it appears at the bottom of page 316, and reads:

     For purposes of argument matching, a nonstatic member function
     is considered to have an extra argument specifying the object
     for which it is called.  This extra argument requires a match
     either by the object or pointer specified in the explicit
     member function call notation (sec. 5.2.4) or by the _first_
     _argument_ _of_ _an_ _overloaded_ _operator_ (sec. 13.4)
     [emphasis mine].  No temporaries will be introduced for this
     extra argument and _no_ _user-defined_ _conversions_ [emphasis
     mine] will be applied to achieve a type match.

There is a supporting example, but no commentary explaining the
reasoning for this rule.   I have run afoul of this rule in two
completely independent cases.  In the first case, it seems that
differing interpretations of the rule by different implementors
has led to a situation where there is no way to define a usable
"operator []" that will be acceptable to both compilers.  If so,
it is a hole in the definition that needs to be (and maybe has
been when I wasn't looking?) addressed in the standard.  In the
second case, the rule results in denial of what I see as a very
handy bit of functionality.  In this case, either I need to
be shown more of the rationale for the rule, so I can accept it
as necessary, or the powers that be (namely all of us that have
a say in how C++ evolves) may want to consider enhancing the
language by relaxing the rule.