ANSI C idea: structure literals

[Karl Heuer]

In article <1988Feb28.130526.4147 at jarvis.csri.toronto.edu> flaps at dgp.toronto.edu (Alan J Rosenthal) writes:
>In article <56 at vsi.UUCP> friedl at vsi.UUCP (Stephen J. Friedl) writes:
>>        struct foo      *table[] = {
>>                & { "Bill",  25 },
>>                & { "Jim",   10 },
>>                & { "Bob",   40 },
>>        };
>
>This is good.  It is an analogue of what happens with strings.  It would be
>good to extend this to arrays and other things.  For example, why not be able
>to write "&3" to get a pointer to int which points to a 3?

(I'll use backquotes `` in running text to avoid colliding with C notation.)

I like the concept of unnamed remote objects, but I'm uneasy about allowing
`&` to apply to a non-lvalue.  I would prefer a more explicit syntax: let's
postulate a keyword `remote` that looks like a function call with two
arguments, the first of which is a type name, and the second an initializer;
the result is an unnamed lvalue of the specified type and value.  Thus,
instead of `&3` we write `&remote(int, 3)`.  The struct example would use
`&remote(struct foo, {"Bill", 25})`.  The existing notation for string
literals can now be described in terms of remotes: `"foo"` is synonymous with
`&remote(char[4], {'f', 'o', 'o', '\0'})`.  (All remotes, like strings in ANSI
C, should be non-writable and poolable at the implementor's discretion.)

This syntax is less kludgy than the other proposals I've seen, and by making
the type explicit we avoid the ambiguities.  Unfortunately it's a bit verbose.
It could be changed from an alphabetic operator to punctuation, but I suspect
the need is sufficiently rare that the longer name is acceptable.

>Of course, [`3` and `(short)3` are] already different when sizeof is used ...

Only on a broken compiler.  In C, `sizeof((short)3)` returns sizeof(int).
(Because `(short)3` is not an lvalue.)

Karl W. Z. Heuer (ima!haddock!karl or karl at haddock.isc.com), The Walking Lint