GCC's statement expression extension

[Linus Torvalds]

In article < 20000726213803N.mitchell@codesourcery.com > you write:

In article < 20000726213803N.mitchell@codesourcery.com > you write:
>>>>>> "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.

Some of the Linux cases could probably be replaced by inline functions.

However, there is one thing an inline function simply _cannot_ do. Not
now, not in the near future. And that's using "typeof". Which is a very
powerful thing indeed, often giving a nicer interface than any amount of
overloading could ever do, with simpler semantics.

So I think you're too harsh on statement expressions.  They are truly a
nice shorthand.  I don't see any badly defined semantics about them in
general: if the only issue with them is strange results from local
labels, then deprecating them sounds like much too harsh a treatment. 

What other problems do the statement expression have? It's certainly no
worse than function nesting, which has much nastier side effects (silly
games with the stack etc). 

And yes, you can get gcc to generate non-sensical code by using local
labels in an expression statement.  But hey, gcc generates non-sensical
code every time you give it nonsensical source - what's the big deal? If
the programmer writes nonsense, then why should the compiler care?

How about a new warning instead:

	strange.c:14: warning: programmer appears seriously deranged

and then let users decide themselves if they really want to use local
labels inside expression statements..

>(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)
>	  ...))

Think about cases where you need to use the same argument value multiple
times, so you need to assign it to a local variable in order to get
"function-like" behaviour.  Join that with the requirement to have
__typeof__, and you can neither use an inline function nor a normal
expression. 

So if you want to clean up the language, why not deprecate and
eventually get rid of nested functions instead - now _there_ is an
abomination from Pascal that should never have been created and that
I've never seen anybody actually use yet (although I wouldn't be in the
least surprised to hear of tons of uses: the perversity of programmers
should never be underestimated). 

		Linus