移除[dcl.init.list#5]中的const会给C++标准及代码带来哪些影响？

首先明确你的代码编译失败的核心原因：当用初始化列表构造std::vector<std::unique_ptr<Foo>>时，标准要求初始化列表对应的临时数组元素是const限定的std::unique_ptr<Foo>。而std::unique_ptr不可拷贝，且const对象无法触发移动构造，因此vector无法完成元素的初始化。

针对你提出的「直接移除该条款中的const」这一假设，以下是具体的问题、对现有代码的影响，以及标准需要调整的内容：

一、违背初始化列表的设计语义 #

初始化列表的核心设计意图是作为只读的临时值序列，开发者普遍预期{a, b, c}这种语法提供的是不可修改的常量集合。如果移除const限定，函数接收std::initializer_list<T>后，可通过const_cast（甚至无需强制转换，若标准调整begin()/end()返回非const指针）修改列表元素，这会彻底打破代码的可预测性。例如：

void modify_list(std::initializer_list<int> lst) {
    *lst.begin() = 42; // 移除const后此操作合法
}

modify_list({1, 2, 3});
// 原本只读的初始化列表被修改，违背直觉且可能引发不可预期的连锁反应

二、大量现有代码会失效或行为异常 #

1. 依赖只读语义的逻辑崩溃 #

很多生产代码依赖initializer_list元素不可修改的特性，比如：

• 假设列表元素不会被外部篡改的业务逻辑函数；
• 模板中通过检测std::is_const_v<typename decltype(lst)::value_type>做分支处理的代码；
• 基于const T*返回值的指针操作代码。

这些代码要么直接出现逻辑错误，要么触发未定义行为。

2. 值语义被破坏 #

std::initializer_list的拷贝是浅拷贝（多个对象指向同一个临时数组），移除const后，修改其中一个initializer_list的元素会影响所有指向该数组的对象：

auto lst1 = {1, 2, 3};
auto lst2 = lst1; // 两者指向同一临时数组
*lst2.begin() = 42;
// lst1的元素也会变成42，彻底违背值语义的预期

3. 类型转换与重载决议混乱 #

现有代码中，initializer_list<const T>可隐式接受{a, b, c}（因为临时数组是const T[N]）。移除const后，initializer_list<T>和initializer_list<const T>的隐式转换关系被打破，大量依赖这种转换的重载决议会失败或匹配错误的重载版本。

三、标准需要连锁调整的内容 #

移除[dcl.init.list#5]中的const限定，并非孤立修改，需要同步调整多个标准条款：

• [initializer_list]条款：std::initializer_list的begin()/end()成员函数当前返回const E*，必须改为E*才能匹配非const数组的类型，这会彻底改变该类模板的接口；
• [dcl.init.list]其他子条款：多处提到初始化列表元素的const特性，比如列表初始化的转换规则、临时数组的类型推导逻辑，都需要重新修订；
• [over.match.list]条款：列表初始化的重载决议规则依赖initializer_list的元素类型限定，移除const后需要重新梳理匹配优先级与转换路径。

四、现有代码是否会大量失效？ #

答案是肯定的：

• 直接失效的代码：所有依赖initializer_list元素只读特性的函数、模板，以及依赖const E*返回值的指针操作代码；
• 行为异常的代码：依赖值语义的initializer_list拷贝操作，会出现跨对象修改的情况；
• 隐式转换失效的代码：大量使用initializer_list<const T>的场景会无法匹配初始化列表。

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