Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!cs.utexas.edu!uunet!world!wmm
From: wmm@world.std.com (William M Miller)
Newsgroups: comp.lang.c++
Subject: Re: namespace (rethought & reiterated)
Message-ID: <1991Mar2.211935.13762@world.std.com>
Date: 2 Mar 91 21:19:35 GMT
References: <1991Feb10.024111.8967@mathcs.sjsu.edu> <11496@pasteur.Berkeley.EDU> <1991Mar2.000018.3360@mathcs.sjsu.edu>
Distribution: usa
Organization: The World Public Access UNIX, Brookline, MA
Lines: 99

horstman@mathcs.sjsu.edu (Cay Horstmann) writes:
> Is ANSI C++ to be a codification of the language, as it exists today,
> warts and all? Then clearly exception handling should NOT be part of it.
>
> Should ANSI C++ give DIRECTION to the language, by eliminating some warts
> (instead of codifying them) and providing genuine improvements (like ANSI
> C did with function prototypes?) I think it should, but obviously many
> people disagree: "It would break existing code..."
>
> Anyway, I think the ANSI committee is by its very nature inclined to be
> very conservative--there are many vendors and users in it with a great
> interest in keeping the status quo. Some netters share that attitude, but
> others do not and keep on proposing new ideas (many of them useful, I think.)

[Please note that the following comments are my personal perspective, not a
statement of policy on behalf of X3J16, X3, or ANSI.]

I believe it is accurate to characterize X3J16 as having a basically
conservative approach to the standardization process.  However, I do not
think that Cay is correct in attributing this conservatism to vendors and
users with vested interests in preserving the status quo.  Instead, I see
several other factors at work.

A large part of our attitude on the committee comes from examining the
experience of X3J11, the C standard committee.  For every change they made,
the C committee had to endure *megabytes* of net flamage from irate critics
claiming they were mad innovators betraying their mandate.  Even to this day
there are still postings complaining about as obvious and apparently
noncontroversial a feature as prototypes.  It's true that there are always
those who propose specific changes or extensions, but the user community as
a whole is fundamentally conservative, desiring to preserve existing
investments in code and training, and achieving anything like consensus in
favor of any given change is a very difficult thing to do.  Look at the
outrage in the FORTRAN and COBOL communities over the innovations being
discussed in their respective standards committees.

Because we realize that there will inevitably be changes we cannot avoid, we
are very cautious about making "optional" changes that would improve
esthetics ("eliminate warts") but that are in no sense mandatory.  Our
credibility and good will in that conservative user community is a limited
resource; we must husband it carefully for use in the battles that really
matter and not squander it over dozens of minor issues.

Someone earlier (sorry, I don't have the article online any more so I can't
attribute it) mentioned the negative experience of language design by
committee.  That is also an issue to which we are sensitive.  The poster
mentioned trigraphs as an example; the more often cited feature is
"noalias," which did not make it into the final C standard but which was
accepted by the committee at one point.  We're even experiencing some of the
trials of design on the fly right now; even though the proposal for
templates has been publicly available for some time, going back to the 1988
USENIX C++ Conference, and was accepted at the July, 1990 meeting, we spent
a good deal of time at the November meeting reconsidering the syntax because
of ambiguities in the current specification, and we'll spend more time on it
in the meeting next week.

The point I'm making is that it's awfully hard to create a language feature
out of whole cloth; user experience is always needed to verify the "safety
and effectiveness" of even small and apparently well-understood changes.
The way to avoid a multiplicity of dialects for new features is to get the
compiler writers to talk to each other (and there's a great deal of that in
the C++ community, happily), not to put something into the standard and hope
that it flies.  Standards have legal implications and are awfully hard to
change; they are not the venue of choice for language innovation.

A final consideration is time.  Given the rate of growth of C++ in both
number of users and number of implementations, we need a firm standard in
place last year, yet even with our intent to reflect the existing langauge
rather than design a new one, we probably won't have one until 1994.  Bjarne
says he has a pile of "useful" suggestions several inches thick; we could
easily be into the next century without a standard if the committee took a
more proactive role in modifying the existing language.  Again, look at the
delays being experienced by more activist standards bodies.

As a final note to this already overlong posting, let me say that exception
handling and templates are special cases for several reasons.  First, there
is almost universal agreement that they are needed in order to achieve the
benefits of reusability and extensibility C++ promises; such unanimity in
favor of other proposed features is going to be hard to come by.  Second,
both are based on proposals that have been very widely disseminated outside
the committee so that the user community as a whole has had the chance to
study and comment.  Third, the original proposal for the standardization
effort accepted by X3 included these two features specifically as within the
purview of the committee's work.  Finally, and very importantly, both
features are pure extensions; the only code that might break as a result of
incorporating them into the standard is that compiled using experimental
implementations, and presumably the owners of that code used those features
with their eyes open to the fact that changes would almost certainly be
required once a standard was adopted.  Many of the other features being
proposed are not nearly so benign.

This is not to say that *no* changes to E&S will be adopted; there have
already been a few, and there will no doubt be more in the future.  However,
proposed changes that are simply "useful" will probably face tough sledding;
only those that address a compelling need that demonstrably outweighs the
above considerations are likely to fly, IMHO.

-- William M. Miller, Glockenspiel, Ltd.
   wmm@world.std.com