generalized lvalues -- patch outline

[Joseph S. Myers]

On Tue, 23 Nov 2004, Ziemowit Laski wrote:

> Under the conditions specified above,
> 
>          (foo)bar
> 
> could be rewritten to
> 
>          *((foo *)&bar)

You seem to be implying that the address of a cast could be taken.  This 
was not part of the old GNU extension.

You are also implying that if "foo" and "typeof(bar)" are not types which 
may alias, then there is runtime undefined behavior by strict-aliasing 
rules.  I don't think this is what you intend.

> > Do you have an analysis of interaction with existing features?
> 
> I don't, although I'm not sure what would constitute "analysis" in this
> context.

Write down the textual amendments to C99+TC1+TC2 and C++03 which would 
introduce your feature.  Examine *every* reference to "lvalue" in either 
of those standards and explain how your changes interact with that 
reference.  That's a *minimum* of analysis that would be needed for this.

> Are you asking, "how are programmers likely to misconstrue what this extension
> does"?  I think most programmers out there would probably be surprised that
> this is an extension at all, since most would expect something like
> 
>    (foo)bar = value;
> 
> to simply "work" :-); so probably the biggest pitfall would be that, even with
> the extension enabled, programmers will still get non-lvalue errors sometimes
> and then wonder why.

People don't need to have read the standards to be aware that casts aren't 
lvalues; for example, having read K&R would suffice.  I don't think we 
should accept random junk just because someone who hasn't familiarised 
themselves with the language might throw it at the compiler: we should 
inform them of the problem with their code and thereby help them to learn 
the languages better.

The use in glibc's RPC headers was not using any actual part of the 
semantics of lvalue casts; it was accidental and e.g. Sun's RPC headers 
achieved the proper specification without needing any lvalue casts or 
similar junk.  I must suspect many other uses are similar.

People expect new major versions to break things.  4.0 is an excellent 
opportunity to deprecate or remove unwise features, of which lvalue casts 
were one.

> Yes, they are all applicable, although any one of them taken separately is
> sufficient justification, IMO.  MS cnd CW compatibility is important because

The removal of crufty code, improving the maintainability of the compiler, 
is sufficient justification for the removal of a dubious extension which 
does not add expressive power to the language.

-- 
Joseph S. Myers               http://www.srcf.ucam.org/~jsm28/gcc/
    jsm@polyomino.org.uk (personal mail)
    joseph@codesourcery.com (CodeSourcery mail)
    jsm28@gcc.gnu.org (Bugzilla assignments and CCs)