Header files with declarations like this:
void FooBar(System::Network::Win32::Sockets::Handle handle, System::Network::Win32::Sockets::Error& error /*, more fully-qualified param
declarations... */);
are common in certain frameworks. And using declarations, which could mitigate this problem, are generally not considered kosher to use in header files because they can effect the name lookup rules for header files that are included later. typedefs inside a class that are declared private clutter up the class' namespace and the namespace of classes derived from it.
Here is a proposed solution:
using {
// A 'using' block is a sort of way to fence names in. The only names
// that escape the confines of a using block are names that are not
// aliases for other things, not even for things that don't have names
// of their own. These are things like the declarations for new
// classes, enums, structs, global functions or global variables.
// New, non-alias names will be treated as if they were declared in
// the scope in which the 'using' block appeared.
using namespace ::std;
using ::mynamespace::mytype_t;
namespace mn = ::mynamespace;
using ::mynamespace::myfunc;
class AClass {
public:
AClass(const string &st, mytype_t me) : st_(st), me_(me) {
myfunc(&me_);
}
private:
const string st_; // string will refer to ::std::string
mn::mytype_t me_;
};
// The effects of all typedefs, using declarations, and namespace
// aliases that were introduced at the level of this block go away
// here. typedefs and using declarations inside of nested classes
// or namespace declarations do not go away.
} // end using.
// Legal because AClass is treated as having been declared in this
// scope.
AClass a("Fred", ::mynamespace::mytype_t(5));
// Not legal, alias mn no longer exists.
AClass b("Fred", mn::mytype_t);
// Not legal, the unqualified name myfunc no longer exists.
AClass c("Fred", myfunc(::mynamespace::mytype_t(5));
In Java and Python individual files are treated in a special way. You can have import declarations that inject names from other namespaces into the file. These names will (well, not exactly with Python, but it's too complicated to explain here) only be visible within that file.
I think C++ needs a similar construct. The existence of the preprocessor, the #include directive, and the C++ concept of a translation unit make the implicit scoping of imported names problematic. So some I think some mechanism for explicitly scoping such temporary aliases is needed.
What problems do you foresee with this idea? If there are no problems, or the problems are very small and fixable, how would I go about submitting it as a proposal to the standards committee?
