为了让编译器、工具和类库实现者跟上节奏，让用户吸收标准C 所支持的编程技术，在早有预计的、沉寂了几年之后，委员会再次考虑语言扩展问题了。"扩展工作组"已建立了，他代替了"演化工作组"。名称的改变（这是Tom Plum的建议）反映了更重要的是语言特性和标准类库工具的集成。我仍然是该工作组的主席。我希望这能够确保C 版本的连贯性和最终结果的一致性。相似的，委员会成员资格也显示了大量人员和组织的连续参和。幸运的是，也出现了很多新的面孔，为委员会带来了新的影响和新的专家意见。
我们打算对语言本身的改变保持谨慎和保守，重点强调兼容性。主要的目的是把主要的努力引导到标准类库的扩展上来。在标准类库方面，我们的目标是大胆进取，利用一切机会。
对于标准类库，我希望根据类库技术报告的要素来建立他，使他成为一个用于系统编程的更广泛的平台。例如，我希望看到用于某些领域的类库，例如目录/文档夹操作、线程和套接字。我还希望委员会同情很多新的C 程式员，提供类库工具支持背景不同的新手（不是新程式员和C的难民）。例如，我希望看到一个使用范围检查STL的标准方法。我对最频繁地被请求添加到标准类库中的标准GUI（图像用户接口）的期望值很低。但是，奇迹有时候也会发生--记得STL吗？
对于语言本身，我希望重点强调支持泛型编程的特性，因为泛型编程是语言的使用取得最大进步的领域。此处，我将调查两个关键部分：
·概念（Concepts）：用于模板参数的类型系统
·初始化器（Initializer）列表：初始化工具的泛化
和以往相同，建议的数量仍然远远超出了委员会能够处理和该语言能够吸收的数量。请记住，接受任何好的建议是不可能办到的。
该语言扩展以支持泛型编程的全部目标是为工具提供更大的一致性，允许我们用泛型直接表示用于解决问题的类。
我的其他优先考虑（和更好地支持泛型编程一起）是更好地支持初学者。现在的建议有一种值得注意的倾向，即这些建议照顾了哪些提出和评估建议的专家用户。有些简单地帮助那些新手的建议经常被忽略了。我认为这是一种潜在的致命的设计偏好。除非新手受到了充分的支持，否则只有很少人能够成为专家。此外，很多人并不希望成为专家；他们希望仍然是"偶然的C 用户"。例如使用C 进行物理计算或控制试验设备的物理学家只有有限的学习编程技术的时间。电脑专家可能会在编程技术方面花费很多时间，而不但仅是期望。我们必须消除那些采用优良技术的不必要的障碍。
一个很简单的例子如下：
| vector<vector<double>> v; |
在98年的C 中，这会导致语法错误，因为>>是个单独的词汇记号，而不是封闭模板参数列表的两个>。V正确的声明可能是：
| vector< vector<double> > v; |
我把他看作是一种阻碍。我曾建议这个问题值得解决，但是当前的规则和演化工作组用一些很好的理由两次拒绝了我的建议。但是，这些理由都是语言技术方面的，而新手（包括其他语言的专家）没有兴趣。不接受第一种（也是十分）明显的v声明浪费了用户和教师的时间。我希望>>问题和其他相似的"阻碍"不要再出现在C 0x中。实际上，我和Francis Glassborow和其他人一起，正在试图系统地消除最频繁发生的这类"阻碍"。
