Re: GCC's statement expression extension

[Mark Mitchell <mark at codesourcery dot com>]

>>>>> "Alexandre" == Alexandre Oliva <aoliva@redhat.com> writes:

    Alexandre> On Jul 29, 2000, Mark Mitchell <mark@codesourcery.com>
    Alexandre> wrote:

    >> There's really no right answer -- the other answer is to wait
    >> until the end of the enclosing full expression.

    Alexandre> It appears to me that this would solve all of the
    Alexandre> problems you've listed so far, and it seems reasonably
    Alexandre> sound to me.  Is there any technical reason why we
    Alexandre> can't do it?

We can implement anything.  :-)

But think how surprising it would be to users to have to explain that
statements in a statement-expression have different semantics from
statements that aren't in a statement-expression.  Essentially, you
then break the invariant that:

  {
    ...
  }

means the same thing as:

 ({
   ...
  });

which is extremely odd.  If you don't clean up temporaries, are you
still going to clean up named objects:

  ({ A a; })

When does `a' get destroyed?  Are you willing to destroy `a' first and
the temporaries that were created before it later, in opposition to
the usual last-in first-out order?  If not, named objects will not be
destroyed at the end of scopes internal to the statement-expression.
Very odd, indeed.

That's what I'm getting at here.  You can define the semantics any
weird way you want, and given N problems you can probably come up with
a semantics that solves all N of them.  What I don't think possible,
unfortunately, is come up with semantics that are consistent, in the
spirit of C++, and easy for users to understand, and will solve the
N+1st problem.

The issue here is that this is not an extension that would pass muster
with the committe -- even the same committee that OK'd many of the
oddities that many programming language theorists don't like, such as
multiple inheritance, virtual base classes, or user-defined
conversion.

I just don't believe this extension makes sense in C++.  It adds no
additional power, it provides no additional cleanliness, affords no
portability.  On the other hand, it has dubious semantics, at best,
and is difficult to implement (especially when you consider using
these things in default arguments.

I think we should be looking at the core issues: how many libraries
make use of this feature, can we ask the library maintainers to phase
out this feature over time, and how many users are using this
extension directly in their own code. 

If the answers to those questions are distinctly unfavorable, then we
may have little choice.  We will have to make up some least bogus
semantics, and go forward.  However, my instinct is that the answers
will be favorable, and we can proceed by first changing the libraries
and then phasing out the extension.  I think that's a process that
will take at least a year.

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