Re: GCC's statement expression extension

[Mark Mitchell <mark at codesourcery dot com>]

>>>>> "Richard" == Richard Henderson <rth@cygnus.com> writes:

    Richard> There are quite a few in the Linux kernel as well.

I'm sympathetic -- people used these things because a) we provided
them, and b) inline functions were not sufficiently optimized.

That's a blemish on GCC's history.  We should not punish our users
twice by ripping these things out from under them.

I think, though, that we should consider deprecating them (and issuing
warnings) in GCC 3.0, and removing them in the next major release.  

    Richard> In addition, glibc uses this extension for things that
    Richard> simply cannot be done with inline functions.  See
    Richard> <tgmath.h>.  Note that the types of these expressions are
    Richard> dependant on the types of the arguments.  This is
    Richard> otherwise impossible in C.  Also note that these
    Richard> functions are defined by C99 -- I suppose the committee
    Richard> was thinking that these would be compiler builtins or
    Richard> something.

Yes, probably.  

(Actually, I bet you can write those functions with only __typeof__
and not statement-expressions:

  # define __TGMATH_UNARY_REAL_ONLY(Val, Fct) \
      (sizeof (Val) == sizeof (double)
       ? ((__typeof__ (Val)) Fct (Val))
       : (sizeof (Val) == sizeof (float)
	  ? (__typeof__ (Val)) Fct##f (Val)
	  ...))

Does that do the trick?  The __typeof__ extension is far less
problematic than statement-expressions -- although even __typeof__ has
serious issues in C++, where the type of an expression can depend on
its context.)

There are certainly things that one can do with statement-expressions
that one cannot do without them.  However, I don't believe this
justifies keeping them indefinitely, given that their many
limitations.

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