Revisiting generalized lvalues

[Michael Krasnik <mike at genlogic dot com>]

I don't know if it's too late, but there is yet another reason
for the use of generalized lvalues besides just ignorance:
using them in macros that verify pointer and struct usage
in a large framework. A comma expression makes it very
convenient, for example (just a general idea):

#ifdef  PRODUCTION
#define X_ABC(x)       ( check( x ), x->abc )
#else
#define X_ABC(x)        x->abc
#endif

which expands

    X_ABC(x) = y;

to:

    ( check( x ), x->abc ) = y;

It is something that is used during development only and
is switched off for the production builds. C++ compatibility
is not an issue either.

Eliminating this construct makes macros much less flexible
and requires much more work for creating self-verifying
frameworks, which is a big issue for small companies with
large codebase. I understand that supporting generalized
lvalues for all possible usage cases (C++, etc.) creates
problems, but why not allowing them for such limited
cases via an obscure special option? GCC always provided
more options that other compilers, it would be sad to see
it changing...

/mike