Regarding the "guest" proposal.

  To summarize, mps@geodesic.com ("A simple but useful proposal") proposes
a new member access specifier "guest:".  Guest members are public and can
only reference other public members.

  Seems like a very good idea to me.  Fine access control is paradigmatic
in C++ and the guest proposal is consistent with the general philosophy of
the language.

  There are many "fat" classes for which a guest declaration would
substantially reduce the mental overhead involved in understanding and
maintaining that class, as well as its derived classes.

  It also seems to be fairly trivial to implement.  Aside from a general
objection to language changes, I cannot think of a single argument against
this proposal.

   An extension (which might legitimately be argued against for complexity
reasons) might allow additional guest function members to be specified
after the original class declaration has been seen, perhaps along the lines
of the following:

#include "classname.h"

guest classname {
 void foo();
 int barf() { return 7;}
};

void classname::foo() { cerr << "foo!\n";}

void f()
{
 classname c;
 c.foo();
 int i = c.barf();
}

   This extension would be nice but it is a little fancy and the original
proposal should be considered separately.

Regarding the "guest" proposal.

  To summarize, mps@geodesic.com ("a simple but useful proposal") proposes
a new member access specifier "guest:".  Guest members are public and can
only reference other public members.

  Seems like a very good idea to me.  Fine access control is paradigmatic
in C++ and the guest proposal is consistent with the general philosophy of
the language.

  There are many "fat" classes for which a guest declaration would
substantially reduce the mental overhead involved in understanding and
maintaining that class, as well as its derived classes.

  It also seems to be fairly trivial to implement.  Aside from a general
objection to language changes, I cannot think of a single argument against
this proposal.

   An extension (which might legitimately be argued against for complexity
reasons) might allow additional guest function members to be specified
after the original class declaration has been seen, perhaps along the lines
of the following:

#include "classname.h"

guest classname {
 void foo();
 int barf() { return 7;}
};

void classname::foo() { cerr << "foo!\n";}

void f()
{
 classname c;
 c.foo();
 int i = c.barf();
}

   This extension would be nice but it is a little fancy and the original
proposal should be considered separately.

Concerning the guest proposal.
Paul J. Lucas writes:
> It can be even more trivially implemented with a comment and
> grouping.

The same thing can be said wrt to private and protected, yet they
make code maintenance so much easier I can't imagine wanting to live
without them.

> Every seemingly little change opens up the floodgates for "what
> about's."

That's what this newsgroup is for.  I'll give a sample modification:

Perhaps the most important value to the proposal is that changing the
protected interface to a class means you have to examine *all* functions
in *all* derived classes to see if they are affected.  This can be
a very large number of functions.  In my experience and in the
commercial libraries I've looked at, the vast majority of member functions
of derived classes exist because they want to add new functionality
to the base class without regard to the base class internals, or because
they are reimplementing the interface of the base class with no reference
to the internals of the base class (redefinitions of virtual functions
generally fall into this category).  This suggests that guests should
have full access to the class they are defined in but only have access
to the public interface of ancestors.

C++ has mechanisms for inheriting interface and implementation (public
inheritance) and for inheriting implementation without interface
(private inheritance).  It seems completely reasonable to me to want
to be able to modify interface without worrying about
inherited implementation.

With good object-oriented design, much programming consists of inheriting
from a library of classes.  Allowing functions to indicate that they are
reimplementing the base class interface or providing additional functionality
without needing special access improves encapsulation, maintainability,
and reuse.  Again, my experience is that most functions would become guests,
so this protection would certainly be worthwhile.  This is especially useful
when a new version of a class library from which you have inherited heavily
comes out.

In all seriousness, the floodgates for getting a simple proposal like
this right will never amount to more than a tiny trickle compared to
the discussions of genuinely complex proposals (e.g. exceptions) that
have been discussed here.

>  Since use of the guest facility can not be enforced, why bother?

Since many programmers use C++ merely as a better C (inline functions, etc.)
why bother with features like public and private, not to mention inheritance.
Remember, C++ is compatible with C, so use of none of its extensions to C
can be enforced.

>  Anyway, forget it.  It has virtually no chance of actually
>  making it into the language.

I wasn't aware that we have to decide how popular a proposal will be
before it is even discussed.  Feel free to have your newsreader ignore
this thread.