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 forum, 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 follow the std-proposals forum by email subscription or via the web forum in order to see and participate in the discussion.)
- Post an initial draft. Using the proposal skeleton in the Call for Library Proposals, write a draft proposal and circulate a link to it on the std-proposals forum to start a second round of discussion. In addition to the points in that skeleton, 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 the next face-to-face ISO C++ standards meeting, where you or a collaborator champion can present it in person for inclusion in the standard.
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 at a face-to-face meeting?
First, plan to attend in person and schedule a time with the subgroup chair. For a proposal to make progress, the proposer (or a colleague/representative who is very familiar with the proposal and the domain) needs to attend in person to present it to the subgroup; proposals without presenters are typically not considered. Please work with the appropriate subgroup chair listed on the committee page to work out a time when you will be at the meeting and the group has availability to schedule your presentation. If you don't know which subgroup 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 with a whiteboard available. 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 face-to-face 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 meetings in person?
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 really can fully substitute for the author, meaning they are intimately familiar with that 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 come to at least one face-to-face 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.