根据 C++ 标准（具体来说是 [over.ics.list]），当发生列表初始化时，编译器尝试将花括号初始化列表匹配到接受 std::initializer_list<T> 的构造函数。这种绑定构成了身份转换（精确匹配），其优先级高于将单个元素匹配到非 initializer_list 构造函数所需的用户定义转换。因此，当使用 {10, 20} 调用构造函数时，像 Container(size_t count, T value) 像这样的构造函数就输给了 Container(std::initializer_list<T>)，因为后者对于花括号初始化列表参数本身不需要任何转换，无论元素是否收窄。
我们在为一个图形引擎设计一个 Matrix 类，该类提供了填充构造函数 Matrix(size_t rows, size_t cols, double val) 和用于字面表初始化的聚合风格构造函数 Matrix(std::initializer_list<std::initializer_list<double>>)。一位初级开发人员编写了 Matrix m{1080, 1920, 0.0}，期待生成一个 1080x1920 的零初始化矩阵，但程序却创建了一个包含三个标量值的 1x3 矩阵，导致了一个微妙的运行时渲染崩溃，在调试过程中很难追踪。
我们最初考虑强制使用括号语法 Matrix(1080, 1920, 0.0) 来绕过 std::initializer_list 重载。然而，这违背了我们编码标准对 C++11 统一初始化的偏好，并创建了一个不一致的 API，部分构造函数需要括号，而其他构造函数则使用大括号。
接着，我们探索了标记调度，通过向填充构造函数添加一个 fill_tag_t 参数，强迫用户编写 Matrix{fill_tag, 1080, 1920, 0.0}。虽然这消除了调用的歧义，但将公共接口弄得杂乱无章，并让期待直观构造函数签名的开发人员感到困惑。
第三，我们尝试通过对模板参数实施 SFINAE 来限制 std::initializer_list 构造函数仅在嵌套括号时激活。这种方法打破了合法的用例，例如 Matrix{{1.0, 2.0}, {3.0, 4.0}}，并引入了脆弱的模板元编程，这增加了编译时间和错误消息的复杂性。
最终，我们选择引入一个静态工厂函数 Matrix::filled(rows, cols, val) 并将三参数填充构造函数设为私有，指引用户使用明确的语法进行基于维度的构造，同时保持 std::initializer_list 构造函数对聚合语法公开。这保留了字面表的直观大括号初始化，而不冒着错误解读维度参数的风险。
重构后的 API 防止了原始错误，使得 Matrix{1080, 1920, 0.0} 变成编译时错误，因为没有匹配的公共构造函数。现在开发人员被迫使用 Matrix::filled(1080, 1920, 0.0) 进行填充操作或 Matrix{{...}} 进行初始化列表，这显著提高了代码的清晰度和安全性。
编译器如何对从花括号初始化列表到非 initializer_list 构造函数的转换序列进行排名，与初始化列表构造函数的身份匹配相比？
根据 C++ 标准的列表初始化重载解析规则，将花括号初始化列表绑定到 std::initializer_list<T> 参数构成了身份转换（精确匹配），其优先级最高。相反，将相同的花括号初始化列表匹配到另一个构造函数时，编译器需要将列表视为带括号的表达式列表，并对每个元素执行用户定义或标准转换。由于身份转换的优先级高于所有其他转换序列，因此即使其元素类型的逻辑匹配通常比替代构造函数要求的更糟，initializer_list 构造函数仍然获胜。
为什么在 C++11 和 C++14 中，auto x = {1, 2, 3}; 推导出 std::initializer_list<int>，而 auto x{1, 2, 3} 在 C++17 及以后成为不合法？
在 C++17 之前，使用 = 符号与 auto 进行复制列表初始化时，花括号初始化列表总是推导出 std::initializer_list。然而，C++17 引入了直接列表初始化的新规则，与 auto 一起使用（没有 =）进行标准模板参数推导：如果花括号初始化列表包含多个元素，推导会失败，因为在这种情况下 auto 无法表示 std::initializer_list，使得程序变得不合法。这一变化消除了直接初始化的“秘密 std::initializer_list”陷阱，但候选人常常忽视复制语法（auto x = {...}）仍然在现代 C++ 中推导出 std::initializer_list，造成了初始化风格之间的微妙不一致。
在什么情况下具有 initializer_list 构造函数和可变模板构造函数的类可能会出现模糊解析，而 std::in_place_t 如何消除它们的歧义？
当一个类同时提供 Container(std::initializer_list<T>) 和 template<typename... Args> Container(Args&&... args) 时，可变参数包可以通过模板参数推导与 initializer_list 构造函数匹配相同的参数。对于 Container c{1, 2, 3}，两个构造函数都是可行的：前者通过花括号初始化列表的身份转换，后者通过推导 Args 为 int, int, int。尽管非模板 initializer_list 构造函数通常赢得平局，但在可变构造函数中添加标签类型，如 std::in_place_t（例如，Container(std::in_place_t, Args&&... args)），强迫用户编写 Container{std::in_place, 1, 2, 3}，确保可变版本仅在显式调用时被引入，而 initializer_list 构造函数默认处理同类花括号列表。