Incomplete type enhancements w.r.t. classes

[DeadMG]

The typical approach to implementing OO in C++ is to devolve it to it's C counterpart in the compiler. Unfortunately, C-style object-orientation, with free functions and opaque handles, has a number of advantages which are denied to classes. So I propose the following additions to the core language:

Firstly, when defining a class type, the members may be incomplete types. This causes the defined class to be an incomplete type. In addition, if defining a data member which is an instantiation of a template, that template is not instantiated until the class is used in a context which requires a complete type. This will enhance modularity in contexts where the class defines data members which are private use only, or referred to in many more TUs than instantiated. Then, only those TUs which need to create the class need include the definitions of those data members. It would also be necessary to require a complete type for the definition of member functions.

Secondly, it would now be legal to call non-virtual member functions on a class which has been defined, but is not complete. This mimics the ability of C to call free functions, passing a pointer to an incomplete type as the first argument.

Thirdly, it should be possible to not require a definition of static member variables (with an implicit definition generated by the compiler in each TU if the programmer did not put a definition in that TU), and where existing static member variable definitions are concerned, to extend their linkage to one per TU, requiring the linker to fold these redundant definitions. Toolchains already have the ability to fold static variables in this fashion, as is required by the Standard for static variables of inline functions, or class templates. Not permitting class-level static variables this same flexibility is unnecessary headache on the part of the user.

These changes would have a key impact of reducing the public headers to those which are truly necessary, and reducing inclusion in all other cases.

[Nicol Bolas]

Or we could just let modules handle this. I don't really see the point of adding a feature that reduces what needs to be in public headers when we're talking about adding a feature that will make all of that irrelevant. Even using module-map files, the recompilation for unimportant header changes will be pretty minimal.