From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24903 invoked by alias); 21 Oct 2002 16:36:01 -0000 Mailing-List: contact gcc-prs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-prs-owner@gcc.gnu.org Received: (qmail 24887 invoked by uid 71); 21 Oct 2002 16:36:01 -0000 Date: Mon, 21 Oct 2002 09:36:00 -0000 Message-ID: <20021021163601.24884.qmail@sources.redhat.com> To: paolo@gcc.gnu.org Cc: gcc-prs@gcc.gnu.org, From: Wolfgang Bangerth Subject: Re: c++/8279: REGRESSION: failure to find a matching function in Reply-To: Wolfgang Bangerth X-SW-Source: 2002-10/txt/msg00781.txt.bz2 List-Id: The following reply was made to PR c++/8279; it has been noted by GNATS. From: Wolfgang Bangerth To: Joe Buck Cc: gcc-bugs@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