bs@alice.att.com (Bjarne Stroustrup)

Re: C++ Language Extensions

9 Jun 93 19:36:46 GMT AT&T Bell Laboratories, Murray Hill NJ

Newsgroups: comp.lang.c++,comp.std.c++

References: <25697@alice.att.com>














             Why Consider Laguuage Extensions?


                     Bjarne Stroustrup

                   AT&T Bell Laboratories
               Murray Hill, New Jersey 07974


                          _A_B_S_T_R_A_C_T

       This paper presents a personal view of the prob-
     lem  of  stability  vs  extensions  when using and
     standardizing C++.  To provide background, I first
     describe  the  general aims of C++ standardization
     and round off the discussion with a description of
     the  current  state  of  affairs  as it relates to
     extension proposals.



_1   _S_t_a_n_d_a_r_d_i_z_a_t_i_o_n _o_f _C++
Formal standardization of C++ started in  December  of  1989
when the ANSI C++ committee, X3J16, was formed.  The initia-
tive came from IBM, DEC, and HP and was supported  by  AT&T.
In June 1991 the effort became officially international with
the creation  of  the  ISO  SC22-WG21.   Thus  a  single  US
national and international C++ standard will emerge.

_W_h_y _s_t_a_n_d_a_r_d_i_z_e _C++?
There are many independently developed C++  implementations.
Therefore, we need a complete and mutually agreed upon defi-
nition of the language.  Otherwise, each user will be locked
into a single ``C++'' implementation which will be incompat-
ible with other ``C++'' implementations.  Also, the emerging
C++ libraries industry would face serious problems trying to
supply users on divergent implementations.
  In the early years, I acted as a clearing house for infor-
mation  and as the keeper of the manual.  In the longer term
that was not acceptable to me or to the C++  community.   It
became  unacceptable to me because it involved too much work
for an individual, and unacceptable to the community because
you simply can't have major segments of the programming com-
munity directly dependent on a single individual
 however well meaning and trustworthy.  For similar reasons,
control  by  a  single  company  is unacceptable.  Being the
keeper of the definition of a widely used  programming  lan-
guage  is  the job of a standards body operating under well-
defined and legally accepted rules.
  It appears that many organizations recognize this  in  the
form  of  rules  that  require  software  to  be  written in

                        June 9, 1993






                           - 2 -


languages that  are  standardized  or  ``under  standardiza-
tion.''   Thus the very start of a standards process makes a
language acceptable.  This surprised me when I  first  heard
of  such  rules,  but  I  have come to conclude that ``under
standardization'' is indeed a reasonable criteria.  The very
creation of an officially responsible body provides a degree
of protection against accidents or  attacks  of  deviousness
that might befall an individual or a company.
  A standards body can act as a forum  for  debate  and  for
dissemination  of  ideas.   That, in my opinion, is the most
important role of the  standards  committee.   Many  members
have  consciously tried to ensure that the C++ committee was
effective in this role.  For example, a standards  committee
is  not  obliged  to  publicize  its activities beyond a few
rather ineffective official channels.  However,  many  indi-
vidual  members  of  the  C++  committees  have made serious
efforts to make the concerns and considerations of the  com-
mittee public and bring the views of the user community back
to the committee.

_W_h_y _o_p_p_o_s_e _s_t_a_n_d_a_r_d_i_z_a_t_i_o_n _o_f _C++?
Given these good reasons, why would anyone  think  standard-
ization of C++ a bad idea or consider the process is fraught
with danger?
  The language is still evolving and a large standards  com-
mittee  is not an ideal forum for language design.  The dan-
ger is ``design by committee;'' that is, the danger of  los-
ing  a  coherent  view  of what the language is and ought to
evolve into in favor of political deals over individual fea-
tures and resolutions.
  A committee can easily fall into the trap of  approving  a
feature just because someone insists it is essential.  It is
much easier to say `yes' than to  say  `no.'   Also,  it  is
always  easier to argue for a feature than to argue that the
advantage of the feature  which will be  very  plausible  in
all  interesting cases is outweighed by nebulous concerns of
coherence, simplicity, stability,  difficulties  of  transi-
tion,  etc.  Also, the way language committees work does not
seem to lend itself well to arguments based on  experimenta-
tion and experience-based reasoning.  I'm not quite sure why
this is, but maybe the committee format  and  resolution  by
voting  favor  arguments  that  are  more easily digested by
tired voters and members oversaturated with information.  It
also  appears  that  logical  arguments  (and sometimes even
illogical arguments) are more persuasive than other people's
experience and experiments.
  Thus, ``standardization'' can become a force for instabil-
ity.   The  results  of such instability can be a change for
the better, but there is always the  danger  that  it  might
become  random  change  or  change  for the worse.  To avoid
this, standardization has to be done at the right stage of a
language's  evolution   after its path of evolution has been
clearly outlined and before divergent dialects supported  by
powerful  commercial  interests has emerged.  I hope this is


                        June 9, 1993






                           - 3 -


the case for C++ and that the  committee  will  continue  to
show the necessary restraint.
  These concerns are valid, and doubly relevant to  concerns
about  extensions.  However, the arguments in favor of stan-
dardizations were accepted by most so standardization  began
and  we  are beginning to see results.  Continuous vigilance
is needed to ensure that ``design by committee'' doesn't put
its stamp on C++.

_A_i_m_s _o_f _C++ _s_t_a_n_d_a_r_d_i_z_a_t_i_o_n
The charter of the standards committee is  ``to  standardize
existing  practice.''   This  involves  producing a document
that describes C++ and is more
    precise
    comprehensive
    comprehensible
than the current manual (the ARM).  That  sounds  easy,  but
anyone  who has looked seriously at standards will know that
the effort is much harder than it sounds  and  fraught  with
both technical and political pitfalls.
  In addition, the work has to be done in a timely manner to
serve the needs of the user community.  The original aim was
to produce a draft for public review somewhere near the  end
of  1993.  The current schedule calls for a draft for public
review September 1994.  I don't see any technical reason why
we shouldn't meet that.

_W_h_a_t _d_o_e_s ``_c_o_m_p_r_e_h_e_n_s_i_v_e'' _i_m_p_l_y?
No two people seem to agree, but  I  suggest  the  following
guidelines:
  [1]Complete description of the language as currently used.
  [2]Standard libraries.
  [3]Enough features for real users.
  [4]Good enough for ``tomorrow.''
Even point [1] can be controversial!  Accepting it precludes
``improving''  the language by making significant incompati-
ble changes and there are always people of suggesting  ``fix
it  now  before  it  is too late  most C++ code is yet to be
written!''  Often, pointing out that  tens  of  millions  of
lines  of C++ production code already exist convinces people
that significant incompatible changes  are  infeasible   but
not  always.  Some take this as an added proof that a change
say banning the C array construct  is urgently needed.   Not
everyone  realizes  that an unrealistic standard will simply
be ignored because the standards bodies  have  no  power  to
enforce  their  rules.  There are no shortage of examples of
standards that had been ignored some deservedly so.
  The C++ committee's decision to look  at  library  classes
such  as  Bitset,  Array, and String that are in common use,
but not in a standard form was popular but by no means unan-
imous.   Some  consider  the provision of standard libraries
desirable but unachievable because  the  design  of  a  good
library  can  be as hard as the design of a good programming
language.  I consider this  observation  valid,  but  not  a


                        June 9, 1993






                           - 4 -


sufficient argument to refrain from trying.  There is a dis-
proportionate advantage in standardizing a  few  frequently-
used  relatively  low-level  classes.  Grandiose schemes, on
the other hand, are completely beyond the abilities  of  the
committee.

_2   _E_x_t_e_n_s_i_o_n_s
Unless a language is unusually complete and the work  of  an
unusually  farsighted designer there will be a need to amend
its definition during the standardization period.  Our prob-
lems and our understanding will have evolved since the first
definition of the language and by the end of  the  standard-
ization  an  unchanged  language  may  be  the  solution  to
yesterday's problems only.  By standardizing a language  you
freeze the set of features available to many users.
  Some programmers are willing to make their own extensions,
and  some  are willing to use extensions supplied by others.
Many, however, are by choice or by various rules  restricted
to  use  the  features  specified  in  a  standard.  Thus it
becomes critical that  the  language  specification  doesn't
contain  glaring  omissions  that  prevent a user from doing
something  essential.   This  is  a  non-trivial  task  that
becomes  even  harder  as  the areas of application increase
with time.  One way of understanding the  continuing  demand
for  extensions  is to see it as part a wish to repair known
deficiencies and part a response to new application areas.

_M_a_n_d_a_t_e_d _e_x_t_e_n_s_i_o_n_s
Two extensions were ``mandated;'' that is, specified in  the
proposal for standardization as additions to be made:
    Templates.
    Exception handling.
The presence of mandated extensions implied that an absolute
policy  of ``no extensions'' was not an option.  In my opin-
ion opening the door for the discussion of extensions was an
important  and  correct  action.  Dealing with extensions in
the context of a standards group  is  not  easy  though,  or
without dangers.

_P_r_o_b_l_e_m_s _w_i_t_h _G_o_o_d _E_x_t_e_n_s_i_o_n_s
Even good extensions cause problems.  Assume  for  a  moment
that  we  have  an extension that everybody likes so that no
time is wasted  discussing  its  validity.   It  will  still
divert  implementor efforts from tasks that some people will
consider more important.  For example,  an  implementor  may
have  a choice of implementing the new feature or implement-
ing an optimization in the code generator.  Often, the  fea-
ture will win out because it is more visible to users.
  An extension can be perfect when viewed in isolation,  yet
flawed  from a wider perspective.  Most work on an extension
focuses on its integration into the language and its  inter-
actions  with  other  language  features.  The difficulty of
this kind of work and the time  needed  to  do  it  well  is
invariable underestimated.

                        June 9, 1993






                           - 5 -


  Any new features makes existing implementations  outdated.
They  don't handle the new feature.  This implies that users
will have to upgrade, live without the feature for a  while,
or  manage  two  versions  of  a  system (one for the latest
implementations and one for the old one).   This  latter  is
especially  the  case  for  library  and tool builders.  For
example, adding a new feature based  on  a  novel  syntactic
construct  will  require updating tools such as syntax based
editors.
  Teaching material will have to be updated to  reflect  the
new  feature  and  maybe simultaneously reflect how the lan-
guage used to be for the benefit of users that  haven't  yet
upgraded.
  These are the negative effects of a ``perfect'' extension.
If  a  proposed  extension  is controversial it will soak up
effort from the committee members and from the community  at
large.   If the extension has incompatible aspects these may
have to be addressed when upgrading from an older  implemen-
tation  to  a  new  one  sometimes even when the new feature
isn't used.  The classical example is the introduction of  a
new keyword.  For example, this innocent looking function
     void using(T* namespace) { /* ... */ }
will break when the features of the namespace  proposal  are
introduced because using and namespace are new keywords.  In
my experience, though, the introduction of new keywords cre-
ates  few  problems and those are easily fixed.  When, as an
experiment, we introduced using and namespace into  a  local
implementation  without  any  announcement  nobody  actually
noticed their presence.
  In addition to the very real problems  of  getting  a  new
feature accepted and into use, the mere discussion of exten-
sions can have negative effects by creating an impression of
instability  in  the  minds  of  some users.  Many users and
would-be users do not understand that changes are  carefully
screened  to  minimize effects on existing code.  Idealistic
proponents of new features often  find  the  constraints  of
stability  and  compatibility  with  both C and existing C++
hard to accept and rarely  do  much  to  allay  such  fears.
Also,  enthusiastic  proponents  of  ``improvements''  often
overstate the weaknesses  of  the  language  to  make  their
extensions look more attractive.

_P_r_o_b_l_e_m_s _w_i_t_h ``_N_o _E_x_t_e_n_s_i_o_n_s?''
What happens if you adopt a policy of ``no extensions?''
  On the positive side, you don't waste any time  discussing
extensions  in  the  standards  committee  and you don't add
ill-defined or unneeded extensions.  This  in theory   gives
more  time  to  work  on  other issues.  However, this added
effort in other areas only manifests itself provided  every-
one actually agrees that extensions are not needed.  Realis-
tically,  people  who  consider  extensions  important  will
devote their efforts to designing and implementing solutions
to their problems whatever a committee  decides.   The  only


                        June 9, 1993






                           - 6 -


difference  is that the work is no longer done in the public
forum of  the  standards  committee.   The  energy  formerly
devoted  to  extensions  is  diverted into the production of
products and dialects.  It  doesn't  go  away,  because  the
problems  that  generate the ideas for extensions don't just
go away.
  On the other hand, people will manage even without  exten-
sions.   Proponents of language features tend to forget that
it is quite feasible to build good  software  without  fancy
language  support.   No  individual  language  feature  is
_n_e_c_e_s_s_a_r_y for good software design, not  even  the  ones  we
would hate to be without.  Good software can be and often is
written in C or in a small subset of C++.  The  benefits  of
language  features  are  in  the  convenience  of expressing
ideas, the time needed to get a program right,  the  clarity
of  the  resulting  code,  and  the  maintainability  of the
resulting code.  It is not an absolute ``either or.''  More
_g_o_o_d code has been written in languages denounced as ``bad''
than in languages proclaimed ``wonderful;'' much more.
  However, if we lack the ability to express something  fun-
damental,  the workarounds used will look more and more ugly
as our understanding the concepts improve.  As time goes by,
code that looked reasonable becomes less acceptable in light
of newer insight.  Consequently,  a  relatively  unsupported
concept  will become the object of a campaign for a language
extension and also the  source  of  techniques,  tools,  and
#pragmas  as  programmers  and  suppliers  adapt  to the new
insight.
  Such tools and techniques are appropriate  in  some  areas
because  no language can directly support every design level
concept, but they can become a burden and  a  source  of  de
facto  dialects.   For  example,  code  depending on special
scaffolding to provide run-time type information or to avoid
clashes   between  global  names  will  typically  not  work
together with code using a different scaffolding  for  those
purposes.  Worse, if non-trivial tools are relied upon, such
as a powerful macro processor or a #pragma that affects  the
semantics  of a program, then we have language dialects that
are most insidious because they are often not recognized  as
dialects.
  Other effects of a ``no extensions'' policy would be  less
tangible,  but  probably not less real.  The excitement many
people feel by being able to  apply  new  techniques  effec-
tively  and being part of an effort to genuinely improve the
lot  of  programmers  would  evaporate.   Basically,  if  we
unwilling  were  to consider new facilities people will look
elsewhere for improvements beyond the current state of C++.
  Also, despite paying lip service to minimalism and stabil-
ity  many  people    _l_i_k_e  new features.  Language design is
intrinsically interesting, the debates  about  new  features
are  stimulating,  and  they  provide  a good excuse for new
articles and releases.  Some features might even  help  pro-
grammers, but to many that seems a secondary motivation.  If
ignored, these factors can disrupt progress.  I prefer  them


                        June 9, 1993






                           - 7 -


to have a constructive outlet.

_L_i_b_r_a_r_i_e_s
More often than people realize, designing  a  library  is  a
better  than  adding a language feature.  Classes can repre-
sent almost all the concepts we need.  Where needed, special
semantics  or  exceptional performance can be implemented by
coding functions in languages other than C++.  An example of
this  is  libraries providing high-performance vector opera-
tions through (inlined) operator functions that expand  into
code tuned to vector processing hardware.
  Since no language can support every desirable feature  and
because  even accepted extensions take time to implement and
deploy, people ought always look to  libraries  as  a  first
choice.   This  is more often than not the most constructive
outlet for enthusiasm  for  new  facilities.   Only  if  the
library  route  is  genuinely infeasible should the language
extension route be followed.

_C_o_n_v_e_r_g_e_n_c_e
Naturally, a standards  committee    _m_u_s_t  stop  working  on
extensions  sometime.  In the case of the C++ committee, the
extensions work will undoubtedly die down towards the end of
1993  in  preparation  for  the draft due in September 1994.
However, the extensions issue will reappear in the  form  of
public  comments  on  that draft  and those comments must be
answered under the rules of the standards committees.   Some
problems  will  not  go  away  just because we would like to
ignore them.
  My personal aim has been to  minimize  extensions  through
thorough  evaluation and design.  My contention is that this
policy  and not a policy of ``no extensions'' will  maximize
the stability and the utility of C++.

_C_u_r_r_e_n_t _S_t_a_t_e
Here are some lists intended to give an  impression  of  the
current state of affairs in the area of suggested extensions
to C++.
Accepted:
    Exception handling (``mandated'')
    Templates (``mandated'')
    European character set representation of C++
    Relaxing rule for return types for overriding functions
    Run-time Type identification
    Overloading based on enumerations
    User-defined allocation and deallocation  operators  for
    arrays
    Forward declaration of nested classes
Rejected or withdrawn:
    Concurrency mechanisms
    Renaming of inherited names
    Keyword arguments
    Several proposals for slight modifications of  the  data
    hiding rules


                        June 9, 1993






                           - 8 -


    Restricted pointers (``son of noalias'')
    Exponentiation operator
    Automatically generated composite operators
     ...
Pending:
    Name spaces
    Mutable (formerly ~const)
    User-defined operator.()
    In-class initialization of class members
    Binary literals
    Extended (international) character sets
    A new syntax for type conversion
    Several template extensions
``Suggested:''
    Garbage collection
    NCEG proposals
    Nested functions
    Boolean type
    Discriminated unions
    User-defined operators
    Evolvable classes / indirect classes
    Anonymous structs
    Enumerations with predefined ++, <<, etc. operators
    Overloading based or return type
     ...
The extension proposals marked ``suggested'' has been infor-
mally presented or even been widely discussed, but no formal
proposal have been brought to the committee.




























                        June 9, 1993