非POD类型使用指定初始化器为何触发RW.DESIGNATOR_FOR_NON_POD警告？

Coverity抛出该警告的核心逻辑是：这类写法要么不符合C++标准规范，要么依赖未形成统一标准的编译器私有扩展，存在明确的兼容性、正确性风险，具体原因如下：

• 标准层面的兼容性问题
  指定初始化器（即.成员名 = 值的初始化写法）最早是C99标准引入的C语言特性，C直到C20版本才正式将其纳入标准，且对适用范围做了严格限制：仅满足“无用户自定义构造函数、无私有/保护非静态成员、无基类、无虚函数”的聚合类型可以使用该语法，且指定成员的顺序必须和成员声明顺序完全一致，不允许乱序、跳跃指定。
  在C17及更早的标准版本中，指定初始化器不属于官方支持的语法，仅能靠GCC、Clang等编译器的私有扩展勉强支持，这类扩展没有统一的行为规范，对非POD类型的处理逻辑各编译器实现差异极大。哪怕结构体整体满足聚合类型的定义，只要其包含非POD类型成员，在C20之前的环境中使用指定初始化器依然属于非标准写法，这也是示例代码中无自定义逻辑的Pair结构体依然触发警告的核心原因。
• 实际运行与维护风险
  POD类型的核心特征是内存布局连续固定、无自定义构造/析构逻辑、可以直接做二进制拷贝。而非POD类型（比如示例中Pair包含的std::string，本身就是有非平凡构造、析构逻辑的非POD类型）如果强行用指定初始化器，会带来几个明确问题：
  1. 初始化行为不可预期：靠编译器扩展支持的场景下，未被显式指定的成员是走默认构造、被零初始化还是直接残留垃圾值，没有统一标准，甚至同个编译器开不同优化等级都可能出现不同结果，很容易触发未定义行为。
  2. 破坏类的封装约束：如果非POD类型自定义了构造函数、维护了内部状态不变式，指定初始化器会直接跳过构造逻辑给成员赋值，很容易破坏类内部的状态约束，引发难以排查的逻辑错误。
  3. 维护成本高：如果后续调整结构体成员顺序、新增/删除成员，基于编译器扩展的指定初始化语法通常不会抛出编译错误，会出现“初始化到错误成员”的静默故障，问题潜伏期极长。

问题复现代码 #

#include <string>
struct Pair
{
    std::string a;
    std::string b;
};

Pair pair = { 
   .b = "B" // Coverity 报警位置：RW.DESIGNATOR_FOR_NON_POD "class type not suitable for use with designators"
}; 

规避方案 #

• 若项目明确启用C++20及以上标准，且确认目标类型是符合标准约束的聚合类型，可合法使用指定初始化器，不会触发风险。
• 若需要兼容C++17及更早标准、或目标类型为非POD/非聚合类型，不要使用指定初始化语法，优先选择显式定义构造函数、按成员声明顺序的列表初始化、静态工厂方法等标准写法构造对象，避免依赖编译器私有扩展。

内容的提问来源于stack exchange，提问作者Коля Кобец