c++/8279: REGRESSION: failure to find a matching function in

[Wolfgang Bangerth]

> > Since the declaration of this class is in namespace std, in looks for this 
> > operator in namespace std. Since both types are in namespace std, Koenig 
> > lookup also does not bring in additional namespaces. It will thus not find 
> > the globally declared operator of the test case.
> 
> But wait a minute: bringing in additional namespaces would possibly make
> additional symbols visible, but the global namespace is already visible.

As you say it, I'm indeed unsure about this: are symbols in the global 
namespace _always_ visible? Or does the compiler only look into the 
_present_ namespace and those introduced via Koenig lookup? I thought it 
was the latter...


> Just the same, it's possible that you are correct.  But if you are
> correct, then the compiler should probably issue warnings whenever someone
> defines an operator in the global namespace that takes two arguments that
> are both in the same non-global namespace, 

Or, more generally: if a function is defined in a namespace and all its 
arguments are in a different namespace. Which unfortunately is not too 
uncommon:

  void parse_string (const std::string &)

Too bad :-(


> The notion that users should casually go about extending the std namespace
> feels wrong to me.  Is that really the intent?

I don't think so.

> > At least, I believe the compiler is right to reject the code, and that 
> > this is not a bug.
> 
> I will ask the folks at comp.std.c++ for an opinion.

Note in this context that there is already a defect report regarding 
similar things. I don't exactly recall what it was about, but the problem 
was something like the above: specifying whether overloading in the global 
namespace (or a user namespace) may change function calls in the library.
Maybe its DR 102 I had in mind 
(http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/cwg_closed.html#102), it even 
has an example almost exactly like yours. The conclusion given there is
  Rationale (10/99): This appears to be mainly a program design issue. 
  Furthermore, any attempt to address it in the core language would be 
  beyond the scope of what can be done in a Technical Corrigendum.

Regards
  Wolfgang

-------------------------------------------------------------------------
Wolfgang Bangerth              email:           bangerth@ticam.utexas.edu
                               www: http://www.ticam.utexas.edu/~bangerth