Doc. no: N1810=05-0070
Date: 2005-04-29
Project: Programming Language C++
Reply to: Howard Hinnant <[email protected]>
Beman Dawes <[email protected]>
Matt Austern <[email protected]>
The C++ standardization committee is now soliciting proposals for a second technical report on standard library extensions, "TR2". The committee will consider both proposals that address entirely new domains, and proposals to modify the existing standard library.
The committee especially welcomes proposals in the following areas:
Although each proposal will be evaluated on its own merits, the committee is more interested in high-level libraries that solve day-to-day problems of application programmers than in low-level infrastructure.
A proposal is more than a wish. "C++ should support JPEG manipulation" is not a proposal. A class synopsis is not a proposal. Even the documentation for a widely used library isn't necessarily a proposal. A proposal should include the following things:
These things are important so that the standardization committee can evaluate whether the proposal solves the problem it's intended to solve. Remember that C++ committee members aren't necessarily experts in whatever domain you're addressing. A clear discussion of motivation and design decisions is more important than finalizing the exact standardese wording. You should expect a proposal to go through at least one revision before it's accepted, so, if the committee likes a proposal, there will be a later opportunity to adjust the precise wording.
The committee prefers proposals that are based on existing practice. Existing practice isn't an absolute rule, but it is an important guideline that the committee can use to judge the risk of a proposal. First, a proposal must be implementable, and the best evidence that something is implementable is that it has been implemented. Second, if a proposal is based on existing practice, the committee can have more confidence that the proposal solves a real problem and that its interface serves the needs of real users.
The preference for existing practice doesn't necessarily mean that a proposal has to be exactly the same as some existing library. A proposal might be adjust an existing library's interface to make it more like the style used elsewhere in the C++ standard, or a proposal might be an attempt to reconcile the interfaces of several preexisting libraries, or a proposal might be based on existing practice in some other language. In rare cases the committee might be willing to adopt a completely experimental library, even without widespread existing practice, if the proposal is sufficiently compelling.
I. Table of Contents
II. Motivation and Scope
Why is this important? What kinds of problems does it address, and what kinds of programmers is it intended to support? Is it based on existing practice? Is there a reference implementation?
III. Impact On the Standard
What does it depend on, and what depends on it? Is it a pure extension, or does it require changes to standard components? Can it be implemented using today's compilers, or does it require language features that will only be available as part of C++0x?
IV. Design Decisions
Why did you choose the specific design that you did? What alternatives did you consider, and what are the tradeoffs? What are the consequences of your choice, for users and implementers? What decisions are left up to implementers? If there are any similar libraries in use, how do their design decisions compare to yours?
V. Proposed Text for the Standard
VI. Acknowledgements
VII. References
Successful proposals for TR1 can be used as models. Examples include:
To submit a proposal: post to comp.std.c++, ask a member of the standards committee to include it as a paper in a committee mailing, or email Howard Hinnant. You can submit a proposal in PDF, HTML, or plain text.
You should either plan to attend a standardization committee meeting yourself (see http://www.open-std.org/jtc1/sc22/wg21/docs/meetings for meeting schedules), or find a committee member who will present your proposal for you. Getting a proposal accepted is an interactive process, and it is almost certain that the committee will have questions. At the least, you need to be willing to respond to email queries.
The standardization committee is working on the second technical report on library extensions ("TR2") at the same time as it is working on the new version of the standard ("C++0x"). The two schedules are decoupled, but it is currently expected that TR2 will be published after C++0x.
Most proposals should be targeted for TR2, not for C++0x. A C++0x library proposal will be judged by much stricter standards than a TR2 proposal. A C++0x proposal will be accepted only if it can be shown to be very low risk and only if the committee is certain that it can be finalized without jeopardizing the schedule for C++0x. Experimental proposals will not be considered for C++0x. For TR2, however, the committee will be less conservative.
Proposals for C++0x library extensions must be received by October 1, 2005. Proposals for TR2 library extensions must be received by October 1, 2006.