JTC1/SC22/WG21 N1314

Doc. no.: J16/01-0028 = WG21 N1314
Date:     17 May 2001
Project:  Programming Language C++
Reply to: Matt Austern <[email protected]>


                 Notes on Standard Library Extensions

INTRODUCTION

At the Copenhagen meeting, J16 and WG21 passed a motion to request a
new work item: a technical report of type 2 on standard library
extensions, an initial version of which should be completed by 2003.

This technical report will not be normative, but the items in it may
be considered for standardization in a future revision of the
standard.  This is particularly important because preliminary
discussion about "C++0x" is already underway; it is likely that a
future revision of C++ will primarily involve expansion of the
standard library, with very few core language changes.

This paper is a preliminary outline of what kinds of extensions the
committee will consider, and how it will do so.  Its purpose is to
summarize some of the Copenhagen discussions, and to stimulate further
discussion.  In some cases I propose questions without proposing an
answer.


SCOPE

The terms of the proposed work item give the committee broad
discretion on what to include in the TR.  For the most part, we expect
that the TR will consist of specific library extensions, in form
suitable for eventual inclusion in a future standard.  It may also be
useful to have a discussion of versioning: if there are changes to the
standard library, how can source and binary incompatibility be
minimized?  Can the namespace mechanism be made to help?

At this early stage, the library working group was reluctant to
identify any possible directions that would definitely be ruled out.
In particular:

 - Both "pure" extensions (new library components that don't affect
   the existing standard library) and "impure" extensions (changing
   existing components to add functionality) may be considered.  Pure
   extensions are preferred, but impure extensions are not necessarily
   ruled out.  For example, it might be useful to think about adding
   finer-grained iterator categories.

 - Library extensions will be considered even if they cannot be 
   implemented on every platform.  For example: there are platforms
   that can support a hosted C++ implementation, but that do not
   support threads or network communication.  Libraries for networking
   and multithreading will be considered, even though they can't be
   implemented on such platform.
    
   A future revision of the standard will have to consider what this
   means: how can we make normative requirements that are not
   universally implementable?  It may be necessary to introduce a
   notion of optional components, as the POSIX standard has in some
   cases.  (There was widespread lack of support for the idea of
   "stub" APIs that fail whenever they're used.)  However, since a
   type 2 technical report is not normative, there is no need to
   decide on the exact details yet: everything in a TR is optional.


Instead of identifying areas that will not be considered, it is
desirable to identify areas that are of particular interest and that
the committee intends to focus on.  It's better to make changes with
specific goals in mind than to make them randomly.  A possible list
is:

A. Filling gaps, and removing obvious embarrassments

   Obvious candidates include hash tables and reference-counted
   pointers.  We can learn about more such candidates by looking at
   the library issues that the library working group has closed as
   "NAD Future", and by talking to people who teach C++ and who can
   tell us about ways in which the library is inconsistent with
   user expectations.


B. Coordination with other standardization efforts 

   The most important standardization effort we should coordinate
   with, of course, is C.  C99 has added a number of library
   components that were not present in C90; all of them should be
   considered as possible C++ extensions.  One obvious example is
   C99's <inttypes.h> and <stdint.h>.

   Other standardization bodies whose work is directly relevant to
   the C++ library include WG20 (internationalization) and POSIX.


C. Additional components for infrastructure

   Examples of "infrastructure" components include pattern 
   implementation classes, policy classes, and traits classes.


D. Better support for specific important application domains

   Such domains might include:
     - text processing
     - numerics
     - graphics
     - system programming
     - networking
     - language bindings, and multi-language programming
   The participation of domain experts would be essential.


CRITERIA FOR EVALUATING PROPOSALS

As a general rule, the standardization committee will not attempt to
design components from scratch: in most cases we will expect to
evaluate and refine proposals.  We will need to develop criteria for
evaluating proposals.

A proposal is not just a suggestion, or an item on a wish list: "We
should add hash tables" is not a proposal.  A proposal should be a
well thought out design, and should include specific text that would
be suitable for a standard.  It should be stylistically consistent
with the existing standard library.  Ideally it should include a
reference implementation, and it should include a discussion of the
reasoning behind the design decisions.

A proposal must make it clear whether the library can be implemented
in standard C++ (as defined in ISO/IEC 14882:1998, is desirable).
Proposals that maintain source and binary compatibility, and that can
be implemented in standard C++ are to be preferred: they are more
immediately useful, and the committee's goal is to minimize core
language changes in future revisions of the standard.  If it turns out
that certain kinds of useful library techniques are not possible
within the confines of standard C++, however, that fact could be
valuable information.  It might be useful for the TR to explore the
boundary between what can and can't be implemented in standard C++.

Proposals can be submitted by committee members, or through national
bodies.  Additionally, the commitee may wish to set up other channels,
much as we have set up informal channels for submitting defect reports
via the Usenet newsgroup comp.std.c++.  We may wish to ask the
moderators of comp.std.c++, or comp.lang.c++.moderated, to act as an
initial filter for library extension proposals.  We may also wish to
ask BOOST to act as such a filter.

Regardless of how proposals are submitted, the committee should make
the process as open as possible and should make it easy for people who
aren't on the committee to submit proposals.  Two concrete suggestions
are:
  - Create model proposal, so people can see what a well-formed
    proposal looks like.
  - Develop some form of interactive submission, so proposers can
    get some help before submission is final.  This implies doing
    some work between meetings: a six-month feedback cycle is too
    slow.