Re: Bogus name lookup by overloaded operators

[Mike Stump <mrs at windriver dot com>]

> Date: Fri, 10 Mar 2000 16:13:05 -0800
> From: "Leonid A. Broukhis" <leob@mailcom.com>
> To: gcc-bugs@gcc.gnu.org

> For context, see http://gcc.gnu.org/ml/gcc-bugs/2000-03/msg00440.html

> Is it me, or somebody in the ANSI committee was not feeling well, to
> put it mildly?

Did you raise this issue when the language was being standardized?
Why not?  Anyway, this part of the standard is mystifying me,
otherwise I might explain it to you.  Please go and ask around on
comp.std.c++ and see if they have a good explanation for it, and see
if you can get them to come up with a recommendation on _how_ you are
supposed to do what you want.

I was kinda surprised we _made_ using not work:

  Each of these declarations that was introduced by a
  using-declaration is considered to be from each sub-object of C that
  is of the type containing the declaration designated by the
  using-declaration.94)

  94) Note that using-declarations cannot be used to resolve inherited
  member ambiguities; see 7.3.3.

otherwise, I would have just said, put in your using decls and be done
with it.

> And speaking of the original example: Why care about ambiguity if none of
> the candidates comprising the ambiguity is a match?

Good point, I think.

I think the issue you found has more to do with the `its too complex'
factor, than a `we meant it to work that way'.

I noticed we put a hack in for builtins:

    For all other operators, the built-in candidates include all of
    the candidate operator functions defined in 13.6 that, compared to
    the given operator,

    - have the same operator name, and

    - accept the same number of operands

:-( Must be because we figured out that we totally blew it and had to
patch it up.  I think the same hack could be extended to cover the
cast at hand, though, lookup would have to be fixed somehow.  We might
be able to get this fixed up for you in the 5 year revision of C++,
but you're going have to complain about it some more (and to the right
people).  I don't know if we'd DR this or not.  I suspect it might be
too encompassing to try and DR it.