Newsgroups: comp.lang.c
Path: utzoo!utgpu!jarvis.csri.toronto.edu!dgp.toronto.edu!flaps
From: flaps@dgp.toronto.edu (Alan J Rosenthal)
Subject: Re: Re: ANSI C idea: structure literals (and short constants)
Message-ID: <8803091705.AA09183@explorer.dgp.toronto.edu>
Organization: University of Toronto
References: <2743@mmintl.UUCP> <2550058@hpisod2.HP.COM>
Date: Wed, 9 Mar 88 12:05:26 EST


decot@hpisod2.HP.COM (Dave Decot) wrote:
>The problem of deciding what their type is solved for now (and possibly
>always) by stating in the standard that such syntax has no inherent type
>and must be cast or assigned to the desired type.

henry@utzoo.uucp (Henry Spencer) responded:
>[expletive deleted]  Speaking as a user and an implementor, this is an
>abortion if there ever was one.

decot@hpisod2.HP.COM (Dave Decot) responded:
>Thank you for the feedback.  But I wonder if you would be so kind as to
>elaborate on this comment ...
>I'm afraid it is not clear to me that all usages of structure constants
>are self-explanatory.

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.  To be specific: "(int)f" is an
expression that gets an int-ish value for the floating expression f.
It doesn't change f.  In your proposal, (struct a){...} and (struct b){...}
imply different values for {...}.  This is very inconsistent, even
worse than the inconsistencies between casting pointers and casting
numerical types.  Also, your (struct ..) cast will produce an lvalue,
which is also a big inconsistency.

I think it's clear that a new syntax, such as Karl Heuer's, is required.
I would prefer a symbol rather than a keyword, but that's just me.
(But: how about any of backquote, dollar, at (@), or right square bracket?
Perhaps unary comma?  Perhaps if the `&' is immediately followed by an
opening brace?)

ajr
-- 
If you had eternal life, would you be able to say all the integers?