🚀 go-pugleaf

    I am not aware of a  having ``change(d) the behavior of struct and union,
    breaking almost all C programs.'' In fact, nothing C++ does to structs
    or unions break any C programs. I suspect rms is misinformed.

My understanding is that the following declaration

   struct foo { int a, b; };

is handled by C++ in a way incompatible with C.  C++ defines `foo' as
a typedef, but C does not.

Is this not so?  I would be glad if it is not.  But if it is, the
incompatibility breaks many C programs because they use the same
symbol both as a structure tag and as a variable (often a variable
whose type is or points to that structure).

The grammar ambiguity shows up in

   int (x);

which could either declare `x' as an integer or convert it to one.

    I think that my design choices in this area traded
    implementor convenience for user convenience.

I don't see that they help the implementors enough to compensate for
the inconvenience to the users.

Users switching from C to C++ wish that C++ were a superset of C.
There is no fundamental or important reason it is not.  The real
features of C++ are upward compatible with C.  The problems are all
superficial.

These problems are insoluble today, but would have been so easy to
avoid at the start.  For example: make `class' do a typedef
automatically but not `struct' or `union'.  Don't use the syntax TYPE
(EXP)--use something like (TYPE) [ EXP ] instead.

An incompatibility that could have been avoided at such small cost
must be considered gratuitous.  It seems that Stroustrup decided
arbitrarily to reject upward compatibility as a goal, and thus
accepted incompatibilities in the absence of any need.