C++删除initializer_list构造函数不生效的底层规则咨询

你观察到的所有行为差异，本质都是聚合初始化的触发规则差异，和C++不同版本的标准定义、编译器实现有关，具体规则如下：

1. 聚合类的判定规则（C++17标准） #

满足以下全部条件的类属于聚合类：

• 无用户提供的构造函数（= default/= delete的构造函数属于用户声明，但不属于用户提供）
• 无私有/受保护的非静态数据成员
• 无虚函数、无虚基类

聚合类支持聚合初始化：使用{val1, val2}语法初始化时，会直接按声明顺序初始化类的公开成员，完全跳过构造函数的匹配流程。

2. 不同场景的行为解释 #

场景1：默认构造函数= default、成员公开 #

此时S完全符合聚合类的定义，return {1,2}走的是聚合初始化流程，根本不会调用任何构造函数，所以你删除的std::initializer_list模板构造函数完全不会被匹配到，自然不会触发报错。

场景2：默认构造函数改为S() {} #

手写实现的空构造函数属于用户提供的构造函数，S不再符合聚合类条件，无法走聚合初始化。此时{1,2}列表初始化会优先匹配std::initializer_list类型的构造函数，正好匹配到你删除的模板构造函数，因此编译器报删除函数引用错误。

场景3：默认构造函数= default、成员改为私有 #

私有成员不符合聚合类的要求，同样不能触发聚合初始化，列表初始化会匹配到你删除的std::initializer_list构造函数，因此报错。且C++的重载决议检查优先级高于成员访问权限检查，所以不会先报成员不可访问的错误。

3. GCC9.3行为异常的原因 #

GCC9.x对C17的聚合类判定规则实现存在缺陷，错误地将「用户声明的= default构造函数」也判定为不符合聚合类要求，所以原始场景下也无法走聚合初始化，直接匹配到删除的构造函数报错，该问题在GCC10及之后的版本已经修复，对齐了C17标准。

4. 正确禁止聚合初始化的方案 #

如果你希望彻底禁止{1,2}这种隐式初始化的写法，只需要让类不再是聚合类即可，可选方案：

• 把默认构造函数改为用户提供的版本（比如你测试的S(){}）
• C20及以上标准可以直接给默认构造函数加explicit修饰：explicit S() = default;，C20起聚合类不允许存在explicit构造函数，因此直接失去聚合初始化资格
• 以上方案不需要额外删除initializer_list构造函数，也能达到禁止return {1,2}的效果。

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