This post addresses the next generation of C++, not
the one immanently to be standardized.

After using C++ on a few large projects, I long for a way
to design classes that are opaque to clients, allowing a
degree of binary compatibility across implementation changes,
without resorting to the letter-envelope idiom or other such
strategies that normally require "needless" heap-allocation.
("needless" as in "needed only to support opacity")

With some language support, it should be possible for client
code to layout opaque objects without any knowledge of their
private data structure.  Certain safeguards would have to be
in place, (as discussed below), but the feature would rely
on a small syntax expansion apparent in this sample:

// Client view of an opaque class:
class CanDoState {
    void[SOME_CONSTANT];                   // Note 1.
public:
    CanDoState( /* 0 or more params */ );  // Note 2.
    virtual ~CanDoState();                 // Note 3.
    CanDoState( const CanDoState & );      // Note 4.
    CanDoState & operator=(const CanDoState &); // Note 5.
    virtual int doWhatCanDo();
};

Notes:
1. The nameless sized void array has no type and therefor
 cannot be copied by any default assignment or copy methods.
2. There is no default constructor since void[] has none.
3. (likewise for destructor)  The out-of-line destructor
 can be virtual or not with all the usual caveats.
4. Without an out-of-line copy constructor, a diagnostic
 would be issued upon any copy attempt by clients.
5. (likewise for assignment)

At this point in a translation, an implementation could
redefine the incomplete type signified with void[] by
redeclaring the class.  Redeclaration would be subject to
semantic constraints enforcing the binary interface seen
in the original declaration.  Only new data members may
appear, and they must fit properly into the gaps reserved
by the void[GAP_SIZE] declaration.  New methods could be
added as long as they are not virtual.  For example, in
a translation preceeded by the above opaque view:

// Implementation view of a once opaque class:
class CanDoState {
    void[];              // Note 6.
    Widget * myWP;
    std::string myWidgetName;
public:
    // There is not much reason to add public methods,
    // but non-virtual ones might be added for use by
    // closely associated classes.
protected:
    inline void doZip() {}
    void refreshWidgetName();
};

Notes:
6. Each sizeless void array ("void[]") declaration is
 matched against an earlier declared sized one.  The
 secret names of opaque classes could reflect the fact
 that they have opaque data regions, so that declaring
 the class without having exposed the client view in a
 translation unit would result in link errors instead
 of definitions incompatible with uses.  (The danger
 is that, without some type-safe linkage convention,
 an implementation might inadvertantly skip the opaque
 declaration and define a class of the same name but no
 cognizance of the data layout compiled into clients.)

I have devised several ways of accomplishing the same
goals that this concept promotes, but they are always
involved and require either excessive casting, a class
factory approach (with heap-allocation), placement new
tricks, or other messy shenanigans.

What I really want is to claim: "I have not changed
anything you clients care about, so let's not rebuild
the world or recall shipped components.", then have my
++C++ compiler help verify such a claim.

--
-- Larry Brasfield
The aforementioned views are mine alone.
(Convert under to dot for e-mail reply.)
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]