From -4839594052539883830
X-Google-Thread: 7894ca11fe,6d978d9a8718e000
X-Google-Attributes: gid7894ca11fe,public,usenet
X-Google-NewGroupId: yes
X-Google-Language: ENGLISH,ASCII-7-bit
Path: g2news2.google.com!news1.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!news.alt.net!frodo.cs.rpi.edu!not-for-mail
From: vandevoorde@gmail.com
Newsgroups: comp.std.c++
Subject: Re: replacing Koenig lookup
Date: Tue, 19 May 2009 15:38:29 CST
Organization: http://groups.google.com
Lines: 63
Sender: cppmods@cs.rpi.edu
Approved: stephen.clamage@sun.com
Message-ID: <37424f1f-77ef-4275-bfff-825d58f8e31b@p4g2000vba.googlegroups.com>
References: <fd118fd5-4b7b-4904-ac43-bc844dcfb96f@j18g2000prm.googlegroups.com>
NNTP-Posting-Host: netlab.cs.rpi.edu
Content-Type: text/plain; charset=ISO-8859-1
To: (Usenet)
Return-Path: <cppmods@ruralroute.cs.rpi.edu>
X-Original-Date: Tue, 19 May 2009 07:29:37 -0700 (PDT)
X-Submission-Address: std-c++@netlab.cs.rpi.edu
Xref: g2news2.google.com comp.std.c++:642

On May 17, 11:50 pm, Michael Kilburn <crusader.m...@gmail.com> wrote:
> Hi,
>
> I am sure everyone here like the idea of changing core language
> feature... ;-) But has anyone ever considered getting rid or better
> replacing 'Koenig lookup'? Personally I never liked it and consider it
> a hack, another type of static polymorphism that conflicts with
> existing mechanisms and produces problems:http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1440.htm(see
> issue #226 and related)
>
> Philosophy behind my reasoning could be shortly explained as:
> - function name is a key to a semantic (obviously, that is why we give
> them meaningful names) and (via static polymorphism) to specific
> functionality (based on argument types and current scope of visibility
> (SoV))
> - 'namespace' concept is a way to separate different semantics that
> are referred using the same name
> - but Koenig lookup hacks/breaks this idea by effectively reserving
> function name regardless of current scope for the same semantic
>
> This obviously was done for a reason, e.g. you would normally expect
> the same semantic for operator+() regardless of scope. Therefore that
> thing that might replace Koenig lookup should be some kind of
> mechanism that will allow to reserve function name on a global level
> (and leave static polymorphism to function overloading) -- as an
> additional bonus it will simplify related chapters in C++
> standard. ;-)
> It does not really matter right now how this mechanism might look
> like. E.g. it could be something like this:
> - magic namespace (e.g. 'global')
> - where you are going to put all names that should have the same
> semantic regardless of current SoV
> - which will behave similar to unnamed namespace (will merge with
> current SoV)
> - therefore when container wants to provide implementation for swap
> function -- all it needs is:
> class Container { ... };
> namespace global { void swap(Container& l, Container& r) { l.swap
> (r); } }
>
> Of course various things (like nested namespaces have to be addressed
> properly and convenient things like allowing 'global' to designate the
> same namespace regardless of current nesting level) will have to be
> addressed before this idea will be mature enough...
>
> What do you think?


I don't think you'll see change in this area for the C++0x time frame.

However, you may be interested in N1691 (Dave Abrahams' "explicit
namespace" proposal) and Herb Sutter's N2103 (a proposal to limit ADL
in some ways).

       Daveed


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



