为何不支持T[N](Args...)语法实现数组元素统一构造？

这个问题问得特别切中要害——我刚学C++的时候也琢磨过：既然单个T对象能用T(args...)顺顺当当构造，为啥数组T[N]就不能直接用同一份参数批量初始化每个元素？逻辑上完全说得通啊！

其实背后主要是历史兼容、语法复杂度权衡这几个原因：

1. 历史包袱：C语言的遗产 #

C是从C演化来的，而C的数组初始化规则非常朴素：要么用花括号列出来每个元素的值，要么依赖默认初始化（全局/静态数组会零初始化，局部数组则是未定义状态）。早期C为了兼容海量的C代码，不敢贸然改动数组初始化的核心语法——要是突然加个T[N](args...)，很可能和现有语法产生歧义，比如编译器会不会把int[3](5)误判成某种奇怪的函数声明？

2. 语法复杂度的权衡：现有方案能满足需求 #

C++标准委员会在加新特性时，会反复掂量“收益”和“语法成本”的比重。而你想要的“批量构造数组元素”的需求，其实用现有语法就能实现：

• 用std::array配合算法（C++11及以后）：

  std::array<MyClass, 4> arr;
  std::generate(arr.begin(), arr.end(), [](){ return MyClass(foo, bar); });
  

• 或者用花括号初始化（如果构造函数不是explicit的话）：

  MyClass arr[4] = {MyClass(foo, bar), MyClass(foo, bar), MyClass(foo, bar), MyClass(foo, bar)};
  

  虽然有点重复，但胜在不需要额外依赖。既然已有替代方案，委员会可能觉得没必要为了这个需求专门引入新语法，徒增语言复杂度。

3. 潜在的语法歧义 #

假设真的引入T[N](Args...)，还可能遇到歧义问题：比如如果T有一个接受size_t的构造函数，那T[5](5)到底是“用5作为参数构造5个T对象”，还是“构造一个数组，其中某个元素用5初始化”？这种模棱两可的场景，会给编译器实现和开发者理解都带来麻烦，标准委员会肯定要尽量避免。

关于你的核心思路 #

其实你提到的“让数组复用单个对象的构造逻辑”这个核心想法，已经被后续的标准和库部分落地了。比如C++20的std::make_array（部分编译器支持）可以更简洁地创建批量初始化的数组，一些第三方库也提供了类似的工具函数。如果这个需求对你来说非常高频，甚至可以自己封装一个简单的函数来实现。

总的来说，这个特性的缺失不是因为逻辑不可行，而是历史兼容和语法设计权衡的结果。要是你觉得这个特性真的很有必要，甚至可以参与C++标准的提案过程——很多实用的新特性都是从社区需求来的！

内容的提问来源于stack exchange，提问作者Ivan Sanz Carasa