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

[Wolfgang Bangerth <bangerth@ticam.utexas.edu>]

The following reply was made to PR c++/8279; it has been noted by GNATS.

From: Wolfgang Bangerth <bangerth@ticam.utexas.edu>
To: Joe Buck <jbuck@synopsys.com>
Cc: gcc-bugs@gcc.gnu.org, <gcc-gnats@gcc.gnu.org>, <Joe.Buck@synopsys.com>,
   <paolo@gcc.gnu.org>
Subject: Re: c++/8279: REGRESSION: failure to find a matching function in
Date: Mon, 21 Oct 2002 11:35:26 -0500 (CDT)

 > > 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