From -4605739133825400829 X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news1.google.com!news.glorb.com!news.alt.net!frodo.cs.rpi.edu!not-for-mail From: Michael Kilburn Newsgroups: comp.std.c++ Subject: Re: replacing Koenig lookup Date: Sat, 30 May 2009 22:03:22 CST Organization: http://groups.google.com Lines: 107 Sender: cppmods@cs.rpi.edu Approved: stephen.clamage@sun.com Message-ID: References: <37424f1f-77ef-4275-bfff-825d58f8e31b@p4g2000vba.googlegroups.com> <3b3b60a7-8bbe-4ec0-9825-447bf5cabc84@p6g2000pre.googlegroups.com> NNTP-Posting-Host: netlab.cs.rpi.edu Content-Type: text/plain; charset=ISO-8859-1 To: (Usenet) Return-Path: X-Original-Date: Sat, 30 May 2009 14:08:05 -0700 (PDT) X-Submission-Address: std-c++@netlab.cs.rpi.edu Xref: g2news2.google.com comp.std.c++:776 On May 26, 12:43 pm, joshuamaur...@gmail.com wrote: > On May 25, 3:25 pm, Michael Kilburn wrote: > > I'd very much prefer getting rid > > of ADL completely and replace with with simple and straightforward > > mechanism of 'global' namespace (which is nothing but an extension of > > existing 'namespace' mechanism) > > Are you being cute by suggesting the global namespace is a new > concept, or are you referring to the current global namespace? I am being cute... > IMHO, I believe the current system would be quite sufficient without > ADL at all. > > [skipped a lot] > > Put another way, I fail to see any real difference between namespace > member functions with namespace member type parameters vs global > functions with a namespace member type parameter. They're effectively > equivalent (barring the not useful case of in ADL defining a function > in the global namespace with the same signature as the namespace > member function. It's not useful because you cannot call either > function without qualifying it, and thus there's no real reason to > create such a function in the global namespace with the same > signature.) I am kind of agree with you... Here are my thoughts: Why we need ADL?: - having function fun(Type v) we would like it to behave polymorphically (wrt arguments's type) -- but this is something that function overloading already does - we also would like to specify given type's overload of func() in the same spot where Type is defined... If Type is defined in a particular namespace -- we'd like to define it there. But then overloading won't work. Essentially, 'global' namespace allows overloading of a function from inside a different namespace: namespace global { void func(int) {...} } namespace ns { class Type {}; void func(Type) { ... } // this will overload global::func() } ns::Type t; func(t); // will call ns::func() namespace another { void foo() { ns::Type t; func(t); // will call ns::func() } } Alternatively 'global' namespace can be replaced by a special devclaration that will mark given function name as 'special' wrt overloading, e.g.: declspec(global_overloading) func; whenever compiler encounters function named 'func' after this declaration -- it will know that this is an attempt to overload (globally reserved) function. > It's probably too late to fix this now as too much code depends on it, I have a feeling that ADL can be replaced with 'global' namespace almost transparently (but of course, I am probably missing smth very obvious) > but ideally ADL should never have existed, and those functions which > we wanted to be found through ADL should have just been declared and > defined in the global namespace. (That is, assuming the goals of ADL > are worthwhile. Alternatively, we could have not had ADL and put all > those functions in the namespace, and require the user to using > declaration / using directive them. However, if you're calling a > function with a namespace member type as an argument, I like that the > function from that library is found without using declaration / using > directive that function as currently done with ADL or as could be done > without ADL if those functions were just global namespace members.) Well, this is what happens with my 'global' namespace, isn't it? Michael. -- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@netlab.cs.rpi.edu] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.comeaucomputing.com/csc/faq.html ]