From -7727695294431845528 X-Google-Thread: 7894ca11fe,6d978d9a8718e000,start X-Google-Attributes: gid7894ca11fe,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news1.google.com!newsfeed.stanford.edu!news.kjsl.com!news.alt.net!frodo.cs.rpi.edu!not-for-mail From: Michael Kilburn Newsgroups: comp.std.c++ Subject: replacing Koenig lookup Date: Sun, 17 May 2009 21:50:42 CST Organization: http://groups.google.com Lines: 55 Sender: cppmods@cs.rpi.edu Approved: stephen.clamage@sun.com Message-ID: NNTP-Posting-Host: netlab.cs.rpi.edu Content-Type: text/plain; charset=ISO-8859-1 To: (Usenet) Return-Path: X-Original-Date: Sun, 17 May 2009 12:44:47 -0700 (PDT) X-Submission-Address: std-c++@netlab.cs.rpi.edu Xref: g2news2.google.com comp.std.c++:632 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? 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 ]