为何make_unique<T[N]>非法而make_shared<T[N]>合法？原因探究

核心结论：并非技术或向后兼容层面的阻碍，主要是缺乏专门的提案推动，以及标准委员会的优先级考量。

1. 技术与兼容层面无实质障碍 #

正如提案n3920中提到的：unique_ptr失去对U[N]的支持令人遗憾，在此我必须指出，shared_ptr对该特性的支持在实现复杂度和规范复杂度上基本没有成本，请不要移除它，反而应考虑恢复unique_ptr<U[N]>的支持。

• 实现复杂度极低：unique_ptr<T[N]>的特化逻辑和shared_ptr<T[N]>类似，只需要在现有unique_ptr<T[]>的基础上，添加固定大小数组的类型匹配逻辑即可，不需要改动unique_ptr的核心机制。销毁固定数组时，同样调用delete[]，和动态数组T[]的销毁行为一致，不存在技术歧义。
• 向后兼容无风险：恢复unique_ptr<T[N]>属于新增特性，不会破坏现有代码。现有unique_ptr<T[]>的用法完全不受影响，新的unique_ptr<T[N]>是独立的模板特化，两者语义清晰区分（前者指向任意大小的动态数组，后者指向固定大小的数组）。

2. 未恢复的核心原因 #

• 缺乏正式提案推动：C++标准的特性落地必须有人提交正式提案、参与委员会讨论并跟进修改。截至目前，没有针对恢复unique_ptr<T[N]>的正式提案进入标准化流程，自然无法推进。
• 优先级考量：标准委员会的精力集中在影响更广、需求更迫切的特性上（比如C20的概念、C23的范围库增强等），unique_ptr<T[N]>属于小众需求，没有足够的社区呼声或工业界需求推动其成为优先级任务。

补充：结合相关问题的说明 #

• 关于make_unique<T[N]>被禁止：早期C++11中unique_ptr本身不支持T[N]类型，因此make_unique也不允许这种写法；如果未来unique_ptr<T[N]>被恢复，make_unique<T[N]>的支持也会同步实现，不存在技术障碍。
• 关于shared_ptr<T[N]>被支持：其核心目的是对齐数组语义，允许传递固定大小数组的类型信息（比如shared_ptr<int[5]>能明确数组长度，而shared_ptr<int[]>不能），这一需求同样适用于unique_ptr，只是没有对应的提案推动落地。

内容的提问来源于stack exchange，提问作者Fuz