Re: GCC's statement expression extension

[Stan Shebs <shebs at apple dot com>]

Mark Mitchell wrote:
> 
> [...]  I suspect that very,
> very few C++ programs contain statement expressions -- except via
> macros in C libraries.

Take a page out of RMS' playbook and start a survey.  There's a
a huge base of GNU users that Eric Raymond calls "dark matter"
because we never hear from them - but they certainly notice when
the compiler no longer compiles their code!  Since those programmers
don't typically have any contact with GCC developers, they just use
whatever constructs they happen to find in the documentation.

> Just refusing to remove the extensions doesn't solve the problems,
> sadly.  These things don't work in C++, and making them work is highly
> nontrivial.  Programs using the standard library don't work, because
> of these decisions, and surprising behavior often results without
> programmer knowledge, because these things are in the standard
> library, not user code.

Do they work some of the time?  If so, then since they're documented
without any caveats for C++, you're stuck with supporting them.

> I think that we cannot do anything until these things are removed from
> glibc.  I think we cannot remove these things from glibc until we make
> some improvements in the compiler to make other options equally
> attractive to the library folks.  And I think we can't remove these
> things from the compiler until we can reasonably expect people to use
> the new libraries.
> 
> On the other hand, the arguments Michael makes apply to almost any
> extension, and I do not agree, by any means, that we must preserve all
> extensions for all time.  The same argument justifies preserving many
> bugs; every time we issue an error that we did not before, we break
> programs.

If you deprecate statement expressions in C++ today, you might be able to
remove them 10 years from now.  Or to be more accurate, you could remove
them today, but it would ruin GCC's reputation.  The documentation is
basically a promise that GCC will make its best effort to conform to
the described behavior; if you break even a small one of the promises
because it's hard to deliver on, what assurance do users have that you
won't later blow off a critical feature if it becomes difficult to implement?

(Bugs don't count because our documented promise is to eliminate bugs,
not preserve them.)

Stan