What problems would you foresee with my 'using block' construct being added to C++?

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 proble开发者_运维技巧ms 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?

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.

Looks confusing to me. The difference between your using block and a regular block is that some names get out, and the rule for which is which seems fairly arbitrary, and people will come up with corner cases that don't work the way you'd expect. Nor do I see what general use this would be.

Can't you do something very much like this with a uniquely-named namespace and some using namespace::foo; statements?

The first thing you should do towards making this, or anything similar, into a standard, is to study some C++ committee documents, which will give you an idea what you will need to do. At the very least, you will need language that can be put into the standard, very good arguments why it would be a good idea, and careful consideration of the pros and cons.

The next thing is to try to get some practice with this, which means coming up with a compiler (likely a changed version of g++) that implements it, and trying to make that popular.

If you can get some real-world use going, you've got a crack at getting into the next standard, not the one currently being finalized, but the one after that. It would help if you could join the Committee, since any new feature is pretty much going to need a champion there. The good news is that they can't keep you out; the bad is that it's going to be expensive, time consuming, and often tedious.

This may sound like a lot, but you're trying to put another feature into a language overloaded with them. You're going to need a really good justification and a lot of work.

You mean like how everybody just has namespaces that they reserve for implementation details? Or how you could just use a class and stick the members as private if you don't want them accessed? It's not that this idea is fundamentally wrong or bad, I just don't see the benefit. C++'s compilation model has much, MUCH larger holes that need fixing rather than a triviality like this.