Do you have a concrete idea for a new feature for the C++ standard library? [Note: See the last FAQ below for how to propose a core language feature.] Here are some suggestions for how to get started turning it into a proposal.
- Float the idea. Post an initial brief description of your feature on the std-proposals mailing list, including especially the problem it solves and alternatives considered. Committee members and other interested experts will be able to give you feedback to let you gauge the level of interest in that kind of feature in general, and also feedback on your specific proposal’s approach to it in particular to help you refine it in the next step. (Note: You will need to subscribe to the std-proposals mailing list in order to participate in the discussion, but you can browse the archives anonymously.)
- Post an initial draft. Using the proposal template at the bottom of this page, write a draft proposal and circulate a link to it on the std-proposals mailing list to start a second round of discussion. In addition to the points in that template, include an Abstract on the cover page -- one or two paragraphs summarizing what the paper is about including a summary of the problem and approach. This draft proposal will have a little more “meat” and detail, and let you get a second round of feedback to see what adjustments in strategy or details other members would like to see that will help the proposal get widespread support.
- Iterate and fine-tune. Update the draft proposal with a new revision to incorporate the feedback you’ve received, and post a new link. Rinse and repeat until you converge on a design that gets general support.
It may take a few rounds of drafting, but once you see the group start to converge and agree on the need to address this problem and in a concrete proposed design, congratulations! You’ll have got a proposal that’s in shape to be submitted as an official numbered paper for consideration at an ISO C++ standards meeting, where you or a collaborator champion can present it in person for inclusion in the standard.
Some FAQs
Q: Does the proposal have to have an implementation? I've heard you can only standardize "existing practice."
There is no ISO requirement that something has to be implemented before it's standardized, only that there is consensus on the feature -- but naturally consensus is easier to achieve when there's a working implementation.
Here is how the library subgroups (and then later the full committee) look on questions regarding existing practice: There is a spectrum, where at one end are proposals so simple that they are acceptable without implementation simply based on inspection of the proposal, while at the other end are proposals so worrisome that they are only acceptable after full implementation and widespread use over many years by users with all sorts of different backgrounds running on a wide range of platforms. Where a proposal falls in this spectrum is an individual decision by each committee member.
Q: What ISO intellectual property policies should I keep in mind when writing a formal proposal paper?
When writing a numbered paper to be submitted for consideration, if you are including possible patented or copyrighted intellectual property belonging to yourself, your employer, or others (including ideas you saw offered in public discussions on this site or elsewhere), please ensure that you have read and conform to the ISO/IEC JTC 1 policies on copyrights, patents, and procedures.
Note that only ISO can definitively interpret and explain these policies, so please direct any questions about them to the ISO Central Secretariat.
Q: How do I present my proposal to the committee?
First, schedule a time with the chair for the relevant subgroup or study group. For a proposal to make progress, the proposer (or a colleague/representative who is very familiar with the proposal and the domain) needs to present it to the group; proposals without presenters are typically not considered. Please work with the appropriate group chair listed on the committee page to work out a time when you will be able to attend the meeting and the group has availability to schedule your presentation. If you don't know which group chair is appropriate, contact another one of the committee officers or subgroup chairs and they'll put you in touch with the right person.
Second, be prepared to open discussion with a short presentation where you are the expert who has done the work to think through this proposal (and are usually also a domain expert) presenting to a room full of C++ experts who are not as familiar with that particular proposal and its domain. Don't assume that everyone has deeply read and understood the paper -- most will have looked at it in advance, but there’s a difference between reading on a page and being able to interact with the domain expert in real time. A primary goal of the presentation is to ramp up the group and be available to answer questions that they have about the paper. The presentation is also your opportunity to “pitch” the key elements and frame the discussion.
The presentation itself can usually be short, but should be as long as necessary to cover the important points. We would suggest trying to summarize things like these, and be prepared with motivating examples if needed to convince the group of a given point:
- Motivation: What’s the problem? Why is it important? What are the key issues to be solved and their relative priorities? Why solve an issue this particular way?
- Design tradeoffs: For example, this part could be solved by doing A, B, or C, here are the advantages/disadvantages of each, and so we’re proposing B.
- Any known open questions: These could include unresolved design choices where we could do A or B or C but haven’t yet decided; for case X we need to get performance data, or need to check that it’s implementable efficiently on Linux; or whatever points you already know need input from the group.
Be prepared that your audience may need "bake time" to come to a consensus, and a successful proposal normally requires multiple standards meetings. Expect that it will take time, including usually time between meetings, for people to digest the information and internalize the issues. So especially in the first presentation it may at first seem like the group is undecided or unclear about their direction. This is normal while the issues and domain essentials are being absorbed, and usually you reach a turning point (possibly even at the first meeting) where it "clicks," people "get it," and the group moves forward strongly to a consensus.
Q: What if I want to write a proposal but I can't attend a meeting?
You need to find someone who can attend and do all of the above effectively for your proposal, including that they support it and deeply understand it as-if the author (and not just for one meeting). It should be someone who can fully substitute for the author, meaning they are intimately familiar with the paper and support it as if they had written it themselves -- and if necessary could take it over and be the author of a subsequent proposal if the original author can't continue.
Q: That's all about new standard library features. How do I propose a new feature for the C++ core language itself?
Carefully; that's a much higher bar, both technically and strategically. If you are interested in proposing a new feature for the core language, we strongly suggest you first attend at least one committee meeting to participate in person. Experience has shown this is necessary to avoid spending your time on proposals that are not sufficiently "baked" and/or unaligned with the direction of the C++ language. The intent is not to exclude anyone -- our meetings are open and observers and new participants are welcome -- but rather to point out that the expertise and experience required to make a good core language proposal is far higher than to propose a new library feature. We want new proposals to succeed, and the orientation you get in person has proven to be essential for that.
Template for Library Proposals
This is a template for a typical proposal for a medium to high complexity feature for the C++ standard library. Proposals for simpler features will go into less detail. You can look at some recent papers for comparison. Many people use the mpark/wg21 or bikeshed tools to produce nicely formatted proposals in a consistent style.
In addition to the section headings given in the template, feel free to use the questions as sub-headings. Italicized text should be replaced by the indicated content.
Document number: PnnnnR0
Date: yyyy-mm-dd
Audience: Library Evolution Working Group
Reply-to: Your name and email address; list multiple authors if applicable. It is OK to obfuscate the address like this: "Jane Proposer <jane at somewhere dot com>I. Table of Contents
II. Introduction
A very brief high level view of your proposal, understandable by C++ committee members who are not necessarily experts in whatever domain you are addressing.
III. Motivation and Scope
Why is this important? What kinds of problems does it address? What is the intended user community? What level of programmers (novice, experienced, expert) is it intended to support? What existing practice is it based on? How widespread is its use? How long has it been in use? Is there a reference implementation and test suite available for inspection?
IV. Impact On the Standard
What other library components does 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 current C++ compilers and libraries, or does it require language or library features that are not part of C++ today?
V. 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?
VI. Technical Specifications
The committee needs technical specifications to be able to fully evaluate your proposal. Eventually these technical specifications will have to be in the form of full text for the standard or technical report, often known as "Standardese", but for an initial proposal there are several possibilities:
- Provide some limited technical documentation. This might be OK for a very simple proposal such as a single function, but for anything beyond that the committee will likely ask for more detail.
- Provide technical documentation that is complete enough to fully evaluate your proposal. This documentation can be in the proposal itself or you can provide a link to documentation available on the web. If the committee likes your proposal, they will ask for a revised proposal with formal standardese wording. The committee recognizes that writing the formal ISO specification for a library component can be daunting and will make additional information and help available to get you started.
- Provide full "Standardese." A standard is a contract between implementers and users, to make it possible for users to write portable code with specified semantics. It says what implementers are permitted to do, what they are required to do, and what users can and can't count on. The "standardese" should match the general style of exposition of the standard, and the specific rules set out in the Specification Style Guidelines, but it does not have to match the exact margins or fonts or section numbering; those things will all be changed anyway if the proposal gets accepted into the working draft for the next C++ standard.
VII. Acknowledgements
VIII. References
The template above is based on the one in N3370 Call for Library Proposals, which also has some other tips for writing a good library proposal. Please note that the "Submission procedures" section in that document are outdated and should not be used. The start of this page describes the new procedures.