This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: GCC's statement expression extension


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

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

We are? I don't see that.  There are already other C extensions that
don't work in C++.  C++ is (still) a changing language.  If we can
deliver better conformance at the price of a rarely used extension, I
bet our user-base will thank us.

We remove "signatures" in a recent release of G++, and I've heard not
one complaint.  I think that was a good decision.  We didn't wait ten
years.

    Stan> If you deprecate statement expressions in C++ today, you
    Stan> might be able to remove them 10 years from now.  Or to be
    Stan> more accurate, you could remove them today, but it would
    Stan> ruin GCC's reputation.

Not necessarily.  If we need to do this to improve conformance, we'll
win with one set of people.  We may lose with another.  This is (as I
said before) something we need to evaluate case-by-case: what are the
penalties, what are the benefits, how many people will be affected,
how do they feel about it.

The C++ user community is very different from the C user community.
C++ users are used to more change in their compilers, from version to
version, and more intent on reaching standards-conformance than C
users.

Look, I'll go back to my secret scheming, and not air it here.  In
order to get where I want to go, I've first got to get this stuff out
of libc, and to do that I've got to be able to claim you don't *need*
this stuff in libc, and that means I've got to somehow get the inliner
to work better.  Coincidentally, we're doing function-at-a-time in C,
and that will help make inlining easier...

This whole discussion was probably premature.

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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]