您是否对 C++ 标准库的新功能有具体的想法？[注：有关如何提出核心语言功能，请参阅下面的最后一个常见问题解答。] 这里有一些关于如何将其转化为提案的建议。
- 提出想法。 在 std-proposals 邮件列表上发布您功能的初步简要描述，其中特别包括它解决的问题以及考虑过的替代方案。委员会成员和其他感兴趣的专家将能够向您提供反馈，让您衡量对此类功能的普遍兴趣程度，并就您的具体提案的方法提供反馈，以帮助您在下一步中完善它。（注意：您需要订阅 std-proposals 邮件列表才能参与讨论，但您可以匿名浏览存档。）
- 发布初稿。 使用本页面底部的提案模板，撰写提案初稿，并在 std-proposals 邮件列表上发布链接以开始第二轮讨论。除了该模板中的要点外，请在扉页上包含一个摘要——一到两段，总结论文的内容，包括问题和方法的摘要。这份提案草案将包含更多“实质”和细节，让您获得第二轮反馈，了解其他成员希望看到的策略或细节调整，这将有助于提案获得广泛支持。
- 迭代和微调。 根据收到的反馈更新提案草案，并发布新链接。反复此过程，直到您达成一个获得普遍支持的设计。
可能需要几轮草稿，但一旦您看到小组开始就解决此问题的必要性以及具体的提议设计达成共识，恭喜！您将拥有一个可以作为官方编号论文提交，以便在 ISO C++ 标准会议上审议的提案，您或合作者可以在会议上亲自提出它，以纳入标准。
一些常见问题
问：提案必须有实现吗？我听说只能标准化“现有实践”。
ISO 没有要求在标准化之前必须实现某些东西，只要求对该功能达成共识——但当然，当有可行的实现时，更容易达成共识。
以下是库小组（以及后来的整个委员会）如何看待有关现有实践的问题：有一个范围，一端是提案如此简单，以至于仅凭对提案的检查就可以接受而无需实现，而另一端是提案如此令人担忧，以至于只有在全面实施并经过各种不同背景的用户在广泛平台上多年广泛使用后才能接受。提案落在这个范围的何处是每个委员会成员的个人决定。
问：在撰写正式提案论文时，我应该注意哪些 ISO 知识产权政策？
在撰写编号论文以供审议时，如果您包含可能属于您自己、您的雇主或他人（包括您在本网站或其他地方的公开讨论中看到的想法）的专利或受版权保护的知识产权，请确保您已阅读并遵守ISO 指令和政策，包括专利政策。
请注意，只有 ISO 才能明确解释这些政策，因此请将有关它们的任何问题直接发送给ISO 中央秘书处。
问：我如何向委员会提交我的提案？
首先，与相关小组或研究小组的主席安排时间。为了使提案取得进展，提案人（或非常熟悉提案和领域的同事/代表）需要将其提交给小组；没有演示者的提案通常不予考虑。请与委员会页面上列出的相应小组主席合作，确定您能够参加会议并且小组有时间安排您的演示的时间。如果您不知道哪个小组主席是合适的，请联系其他委员会官员或小组主席，他们会为您联系到合适的人。
其次，准备好通过简短的演示开始讨论，您是思考此提案（并且通常也是领域专家）的专家，向一群不熟悉该特定提案及其领域的 C++ 专家进行演示。不要认为每个人都已深入阅读和理解了论文——大多数人会提前看过它，但阅读页面和能够实时与领域专家互动之间存在差异。演示的主要目标之一是让小组迅速掌握情况并能够回答他们对论文提出的问题。演示也是您“推销”关键要素和构建讨论的机会。
演示本身通常可以很短，但应足够长以涵盖重要点。我们建议尝试总结以下内容，并在需要时准备好激励性示例以说服小组接受给定观点
- 动机：问题是什么？为什么它很重要？需要解决的关键问题是什么，它们的相对优先级是什么？为什么以这种特殊方式解决问题？
- 设计权衡：例如，这部分可以通过 A、B 或 C 来解决，这里是每种方法的优缺点，因此我们建议 B。
- 任何已知的未解决问题：这可能包括尚未决定的未解决设计选择，例如我们可以做 A 或 B 或 C 但尚未决定；对于情况 X，我们需要获取性能数据，或者需要检查它是否可以在 Linux 上高效实现；或者您已经知道需要小组投入的任何其他要点。
请准备好您的听众可能需要“消化时间”才能达成共识，并且一个成功的提案通常需要多次标准会议。预计这将需要时间，通常包括会议之间的间隔时间，以便人们消化信息并内化问题。因此，特别是在第一次演示中，小组一开始可能看起来犹豫不决或方向不清。这是正常现象，因为问题和领域要点正在被吸收，通常您会达到一个转折点（甚至可能在第一次会议上），在那里它“点击”了，人们“明白了”，小组坚定地向前推进达成共识。
问：如果我想撰写提案但无法参加会议怎么办？
您需要找到一个能够出席并为您的提案有效完成上述所有工作的人，包括他们支持并深入理解它，就像作者本人一样（而不仅仅是一次会议）。这个人应该能够完全替代作者，这意味着他们对论文非常熟悉并支持它，就像他们自己写的一样——如果需要，如果原作者无法继续，他们可以接管并成为后续提案的作者。
问：这些都是关于新标准库功能的。我如何为 C++ 核心语言本身提出新功能？
谨慎；这是一个高得多的门槛，无论是在技术上还是战略上。如果您有兴趣为核心语言提出新功能，我们强烈建议您首先至少参加一次委员会会议以亲自参与。经验表明，这是必要的，以避免将时间浪费在不够“成熟”和/或与 C++ 语言方向不符的提案上。目的不是排除任何人——我们的会议是开放的，欢迎观察员和新参与者——而是指出，提出一个好的核心语言提案所需的专业知识和经验远高于提出一个新库功能。我们希望新提案能够成功，而您亲自获得的指导已被证明对此至关重要。
库提案模板
这是 C++ 标准库中中等或高复杂性功能的典型提案模板。针对更简单功能的提案将不那么详细。您可以查看最近的一些论文进行比较。许多人使用 mpark/wg21 或 bikeshed 工具以一致的风格生成格式精美的提案。
除了模板中给出的章节标题外，请随意使用问题作为副标题。斜体文本应替换为指定内容。
文件编号： PnnnnR0
日期： yyyy-mm-dd
受众： 库演进工作组
回复至： 您的姓名和电子邮件地址；如果适用，请列出多位作者。可以像这样混淆地址：“简·提案者 <jane at somewhere dot com>一、目录
二、引言
对您的提案进行非常简短的高层概述，应让不一定是您所涉及领域专家的 C++ 委员会成员也能理解。
三、动机与范围
为什么这很重要？它解决了哪些类型的问题？目标用户社区是什么？它旨在支持哪个级别的程序员（新手、有经验的、专家）？它基于哪些现有实践？它的使用范围有多广？它已使用多长时间？是否有可供检查的参考实现和测试套件？
四、对标准的影响
它依赖于哪些其他库组件，又有哪些组件依赖于它？它是一个纯粹的扩展，还是需要更改标准组件？它是否可以使用当前的 C++ 编译器和库实现，或者它是否需要目前不属于 C++ 的语言或库功能？
五、设计决策
您为什么选择您所做的特定设计？您考虑了哪些替代方案，它们的权衡是什么？您的选择对用户和实现者有什么影响？哪些决策留给实现者？如果在使用中有任何类似的库，它们的设计决策与您的相比如何？
六、技术规范
委员会需要技术规范才能充分评估您的提案。最终，这些技术规范必须以标准或技术报告的完整文本形式呈现，通常称为“标准语言”，但对于初步提案，有几种可能性
- 提供一些有限的技术文档。这对于一个非常简单的提案（例如单个函数）可能可以接受，但对于超出此范围的任何提案，委员会可能会要求更多细节。
- 提供足够完整以充分评估您的提案的技术文档。此文档可以包含在提案本身中，或者您可以提供指向网络上可用文档的链接。如果委员会喜欢您的提案，他们将要求修改后的提案包含正式的标准语言措辞。委员会认识到，为库组件编写正式的 ISO 规范可能令人望而却切，并将提供额外的信息和帮助，以帮助您入门。
- 提供完整的“标准语言”。标准是实现者和用户之间的契约，旨在使用户能够编写具有指定语义的可移植代码。它规定了实现者被允许做什么，他们被要求做什么，以及用户可以和不能依赖什么。“标准语言”应符合标准的总体阐述风格，以及规范风格指南中规定的具体规则，但它不必与确切的边距、字体或章节编号匹配；如果提案被接受到下一个 C++ 标准的工作草案中，这些都将更改。
七、致谢
八、参考文献
上述模板基于 N3370 库提案征集 中的模板，该文档也包含一些编写良好库提案的其他技巧。请注意，该文档中的“提交程序”部分已过时，不应使用。本页开头描述了新程序。