Question

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?

Answer 1

The ISO/IEC JTC1/SC22/WG21 (aka C++) standards committee is close to finishing the C++0x standard; you have essentially no chance of getting this proposal into the C++0x standard.

For any proposal, you have to present the motivation for the feature, explaining why this should be added to the standard instead of the 50 other proposals contending for the privilege. (See Stroustrup’s explanation in D&E – ‘Design and Evolution of C++’.)

You also benefit from having an implementation in place, which is available and used, so people have hands-on experience of the feature at work. While it remains abstract and unimplemented, you run the risk of repeating the export fiasco, and the committee tries to avoid repeats of that. One advantage of this is that it helps build your constituency of people who are interested in using your feature. If you can’t build such a constituency, maybe your proposal isn’t worthy of inclusion in the standard.

What you’ve given here might be an interesting start, but it is not yet anywhere near what would be needed to get to a standard proposal. Take a look at the documents on the Open Standards web site. Consider whether you have the resources at your disposal to take this forward. The chances are that you do not, I’m sorry to say.