Why aren't internally included namespaces private? - c++

Question

Or in other words, why allow this to compile?:
#include <iostream>
namespace N{
using namespace std;
string bar() { return "bar";}
void foo() { cout<<"foo\n"<<bar()<<endl; }
}
int main(){
N::foo();
N::cout<<">why allow this??\n"; //Can't ::N:: keep `::std::` to itself?
}
Why not have each namespace resolve its inner include directives internally and only "export" what's actually in that namespace?
Making it work like that would eliminate the need to use fully qualified names inside namespace blocks in most places and I can't think of the drawbacks.
Does this behavior have any purpose besides making things possibly easier on implementers?
Edit:
Turns out it behaves at least somewhat sensible in that there's no contention between a current namespace (B) and an included (using directive'd) namespace (C)—the current namespace (B) always wins. However if the current namespace (B) is included elsewhere (A) then suddenly, the suddenly, B and C start competeting, which must be weird for the user of B who never even knew about C:
#include <iostream>
namespace C {
void method() { std::cout<<"C\n"; }
void cmethod() { std::cout<<"cmethod\n"; }
}
namespace B { using namespace C;
void method() { std::cout<<"B\n"; } }
///^^Library
///>User code
namespace A {
using namespace B;
void aMethod() {
//method(); Error:
//conflict between B::method and C::method even though A doesn't even know about C
B::method(); //Why do I need to write this when I just included B?
cmethod(); //This simply leaks from C because of the u-directive
}
}
int main() { A::aMethod(); }

Answer 1

As far as I can tell, this feature has been explicitly introduced by N0635, proposed by Bjarne Stroustrup himself. The first reason mentioned in that proposal why this feature should be introduced is because he has been "repeatedly asked to make this work:"
namespace A {
int f();
}
using namespace A;
void g()
{
::f(); // call A::f
}
and this
namespace A {
int f();
}
namespace B {
using namespace A;
}
void g()
{
B::f(); // call A::f
}
Under the current rules, this doesn’t work because B::f means "look
for an f declared in B" and f isn’t declared in B.
There are additional reasons mentioned in that paper, though:
One could argue that this interpretation is closer to the way B::f
always worked for a base class B. A benefit would be a
simplification of the library headers because
namespace std {
int printf(const char* ... );
// ...
}
using namespace std;
int main()
{
::printf("Hello pedantic world\n");
}
would now work. It this relaxation is accepted, I would expect the
standard .h headers to be changed to use using-directives (as
originally intended) rather than using-declarations. This would save
hundreds of lines of declarations.
Also, if someone takes
static void f(char);
void f(int);
void g()
{
::f(’a’); // calls f(char)
}
and naively translates it to
namespace { void f(char); }
void f(int);
void g()
{
::f(’a’); // current rules: class f(int)
// relaxed rules: calls f(char)
}
then there would be a change of meaning under the current rules, but
not under my suggested new rules. Some people have worried about the
change of meaning implied by the current rules.
People have responded to this proposal with remarks like "obvius,"
"that was what I always meant," and "I thought that was what it did."
I consider that an indicator that the relaxation will not lead to
added teaching problems, but might reduce such problems.

Answer 2

In fact, namespaces didn't exist in the original version of The C++ Programming Language (1986). They were introduced later, with the aim to manage logical grouping of elements. The ability to compose new namespaces out of other existing namespaces was part of desired features (see section 8.2.8 of the current version of Stroustrup's book).
The standard being as it is, the real question would be: is using the std namespace inside your own one is a good practice in view of Herb Sutter's recommendations ? This would probably be safer:
// === For exposure in a header ====
namespace N{
std::string bar(); // std:: because not sure std is used in the surrounding context
void foo();
}
// === For use in the implemenation ===
using namespace std; // for the implementation
namespace N {
string bar() { return "bar";}
void foo() { cout<<"foo\n"<<bar()<<endl; }
}
The current namespace logic has also advantages. You could for example manage different versions of an library, still allowing for use of legacy parts during a transition period, through explicit scope resoultion.
namespace my_super_lib {
namespace my_super_lib_v1 { // legacy API
void super_f() { std::cout<<"1"; }
void super_old() {} // obsolete,
}
namespace my_super_lib_v2 { // new API
void super_f(int a) { std::cout<<"2"; }
}
using namespace my_super_lib_v2; // use now the new API
using my_super_lib_v1::super_old; // but still allow some legacy
};
Stroutrup's FAQ shows similar examples with in addition a clear case for inline namespaces.

Answer 3

Well, if you don't want that to happen, don't do using namespace std or similar inside the namespace N...
It is actually quite useful sometimes to be able to "export" something from one namespace into another. Imagine that I've got this clever set of functions to do flubbetiflap functionality. To this goal, I'm borrowing a set of functions in the kerflunk namespace, which provides some really useful type declarations I want to use in my functionality. So I can do:
namespace flubbetiflap
{
using namespace kerflunk;
... all the good code what I wrote to do flubbetiflap goes here ...
};
Now, the users of my flubbetiflap won't actually need to know that I'm using kerflunk for my implementation.
Sure, there could be all sorts of atlernative solutions that one COULD come up with for doing this. But I can certainly see how it can be useful.
Obviously, nobody outside of the C++ committee would actually know much about the discussion that went on to determine how this should work...