Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!ames!eos!aurora!labrea!decwrl!pyramid!prls!philabs!pwa-b!mmintl!franka
From: franka@mmintl.UUCP (Frank Adams)
Newsgroups: comp.lang.c
Subject: Re: ANSI C idea: structure literals (and short constants)
Message-ID: <2768@mmintl.UUCP>
Date: 15 Mar 88 22:03:55 GMT
References: <12244@brl-adm.ARPA>
Reply-To: franka@mmintl.UUCP (Frank Adams)
Organization: Ashton-Tate Corporation, East Hartford Development Center
Lines: 31

>They're not, but the point is that this is a totally new meaning for a
>cast.  Usually, a cast is a unary operator.  Here, it's part of the
>description, like a declaration.  ...  In your proposal, (struct a){...}
>and (struct b){...} imply different values for {...}. ...  Also, your
>(struct ..) cast will produce an lvalue, which is also a big inconsistency.

This is the wrong the interpretation of this syntax.  If such a syntax is
adopted, the correct interpretation runs as follows:

	An expression of the form {...} is of an anonymous struct type,
	whose components are unnamed, and have the types of the
	expressions given.  Casting a struct to another struct results
	in an element by element cast of the components of the first
	struct to the components of the second.  Likewise for casting a
	struct to an array.

	Taking the address of a constant results in a literal copy of
	the constant being allocated, and the result is a constant
	pointer to that literal.

I don't believe that K&R anywhere specify the semantics of casting structs;
perhaps X3J11 does.  I am sure that there is a fair amount of (non-portable)
code out there which assumes that such casts are interpreted as "take as".
Just how much, I don't know.

The main problem with this proposal is the parsing problem.  When do {}'s
enclose a struct literal, and when a compound statement?  The parser
must be able to tell when it sees the first {.
-- 

Frank Adams                           ihnp4!philabs!pwa-b!mmintl!franka
Ashton-Tate          52 Oakland Ave North         E. Hartford, CT 06108