Re: GCC's statement expression extension

[Mark Mitchell <mark@codesourcery.com>]

>>>>> "Stan" == Stan Shebs <shebs@apple.com> writes:

    Stan> I get the sense that you wish this wasn't a discussion
    Stan> topic, but that's wrong thinking; if you're contemplating

No, not at all.  All I'm thinking is that I started a firestorm with a
casual comment, and that I didn't really mean to.  Basically, I feel
like some people are saying categorically that we can't remove
extensions, even ones that don't work, aren't widely used, etc., and I
don't buy that.  I think we need to take things case by case.

In particular, if a ton of people use something then of course we have
to be considerate of that.  If, however, only a few people use
something and it causes real pain either to us or to other users, then
we might decide to nix some extension.

As for statement expressions in C++, I think you should caution your
users not to use them.  Not because they might go awa, but because
they don't have documented semantics in C++ (for example, when does a
temporary created in the statement expression go away?), because there
are known bugs in the C++ implementation of statement expressions that
are hard to fix, because using them is unportable, and because there
are better ways to provide equivalent functionality in C++.

The reason I'd like to drop this discussion is that I don't think it's
productive *at this time*.  We're not going to drop
statement-expressions in C++ until we know that that will work
technically -- and that requires *at least* looking at the glibc
headers and kernel headers.  Then, we have to decide whether we can do
it from the point of view of the number of users, how they use the
extension, etc. -- all the things you suggest.

Note that I suggested that we could perhaps deprecate this extension
in the next release.  (We can only do that if we solve the technical
problems, because we don't want people seeing lots of bugs warnings.)
That's a nice solution because it allows us to back off of removing
the feature if we get lots of complaints about the deprecation.
Simultaneously, it puts follks on notice that they're using some funky
features that they should think twice about using.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com