Undelivered mail

MAILER%ALASKA.BITNET at CUNYVM.CUNY.EDU MAILER%ALASKA.BITNET at CUNYVM.CUNY.EDU
Sat Mar 12 08:59:30 AEST 1988


Subject:  Re: Re: ANSI C idea: structure literals (and short constants)

[Non-Deliverable:  User does not exist or has never logged on]

Reply-To: Info-C at BRL.ARPA

Received: From UWAVM(MAILER) by ALASKA with Jnet id 4501
          for SXJVK at ALASKA; Fri, 11 Mar 88 13:04 AST
Received: by UWAVM (Mailer X1.25) id 3101; Fri, 11 Mar 88 14:03:16 PST
Date:         Wed, 9 Mar 88 17:05:26 GMT
Reply-To:     Info-C at BRL.ARPA
Sender:       Info-C List <INFO-C at NDSUVM1>
From:         Alan J Rosenthal <flaps at dgp.toronto.EDU>
Subject:      Re: Re: ANSI C idea: structure literals (and short constants)
Comments: To: info-c at brl-smoke.arpa
To:           Vic Kapella <SXJVK at ALASKA>


decot at 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 at utzoo.uucp (Henry Spencer) responded:
>[expletive deleted]  Speaking as a user and an implementor, this is an
>abortion if there ever was one.

decot at 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?



More information about the Comp.lang.c mailing list