Path: utzoo!mnetor!uunet!husc6!cmcl2!brl-adm!adm!MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU From: MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU Newsgroups: comp.lang.c Subject: Undelivered mail Message-ID: <12326@brl-adm.ARPA> Date: 12 Mar 88 21:06:54 GMT Sender: news@brl-adm.ARPA Lines: 70 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@BRL.ARPA Received: From UWAVM(MAILER) by ALASKA with Jnet id 8434 for SXJVK@ALASKA; Sat, 12 Mar 88 11:39 AST Received: by UWAVM (Mailer X1.25) id 5734; Sat, 12 Mar 88 12:38:38 PST Date: Fri, 11 Mar 88 04:10:06 GMT Reply-To: Info-C@BRL.ARPA Sender: Info-C List From: Dave Decot Subject: Re: Re: ANSI C idea: structure literals (and short constants) Comments: To: info-c@BRL-SMOKE.arpa To: Vic Kapella > 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. > > 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. No, I intend that as far as the language is concerned, {...} is an expression that has a value, but there are only two operations defined on such values: assigning it to an lvalue using '=', or casting it to the appropriate aggregate type. This concept is somewhat the cousin of (void *), which generates pointers to values that are not usable directly; such pointers must be cast to some other pointer type before the object to which they point can be used. > To be specific: "(int)f" is an > expression that gets an int-ish value for the floating expression f. > It doesn't change f. Depends on what you mean by "f". This cast changes the bit pattern used for representing the value, surely. Pointer casts change the type of the value to which the expression points, which may give them a completely different abstract interpretation. > In your proposal, (struct a){...} and (struct b){...} imply different > values for {...}. What do you mean by "different values"? Of course they are different, they're of different types! If you mean "bit patterns", this is also true of your cast example above. Anyway, this same syntax represents the same type of typeless value that could be said is used for initializers; the value of these depends on the type of the variable which it initializes. > This is very inconsistent, even worse than the inconsistencies > between casting pointers and casting numerical types. It's more similar to casting numerical types than casting pointers, and I think it should be, in order to make these things look like constants. > Also, your (struct ..) cast will produce an lvalue, > which is also a big inconsistency. That is a misinterpretation, and I'm not sure how you arrived at it. Cast only produce rvalues; I assumed this would be obvious. Dave Decot hpda!decot