Path: utzoo!mnetor!uunet!husc6!cmcl2!brl-adm!brl-smoke!gwyn
From: gwyn@brl-smoke.ARPA (Doug Gwyn )
Newsgroups: comp.lang.c
Subject: Re: ANSI C idea: structure literals
Message-ID: <7422@brl-smoke.ARPA>
Date: 6 Mar 88 20:02:23 GMT
References: <56@vsi.UUCP> <1988Mar3.183939.945@utzoo.uucp> <7415@brl-smoke.ARPA> <1988Mar5.213746.12022@utzoo.uucp>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 36
Keywords: ANSI, structure literals

In article <1988Mar5.213746.12022@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes:
>> >... "Need not convincingly shown; existing constructs can be used to
>> >same effect; lack of implementation experience in C."
>> I think a good case could be made for some such facility...
>Um, Doug, please explain how said good case would refute any, let alone
>all, of the three objections I cited.  Note that the first objection says
>"need", not "wish".  For heaven's sake, have we forgotten that X3J11's
>supposed mission was to *standardize* C, not redesign it?!?

I meant that I think it could be reasonably argued that there IS a need
for such a facility.  In its absence, we've been resorting to kludges
using "awk" scripts and such to help build initializer tables as separate
files which are then #included at compile time.  This requires introducing
a lot of unique struct names that are of no value to the programmer other
than part of the workaround.  It is embarrassing to admit that this could
have been solved by adjusting the language design, but wasn't.

If you haven't run into this problem, consider yourself fortunate.

It isn't absolutely necessary to have had previous implementation
experience with a proposed feature, if it is clear to everyone how
it would be implemented and what the consequences would be.

Certainly, just because a feature is a "nice idea" is not sufficient
reason to toss it into the standard, but when an idea solves an existing
real programming problem in a clean way it is worth considering.  Part
of the charter of X3J11, apart from standardizing the common part of
existing practice, is to find fixes for problems in existing practice.
(If existing practice were free of problems, there would be no need for
a standard!)

At this point my feeling is that X3J11 will not want to add any more
"features" to the language, since they're trying to get the final
standard published as soon as possible.  However, if an extremely strong
case can be made for a new proposal, I'm sure it will still receive
serious consideration.