C++中UTF-8与宽字符串字面量拼接为何未被归为条件支持？

在翻译阶段6（5.2）中，相邻的string-literals会被拼接。如果两个string-literals拥有相同的encoding-prefix，拼接所得字符串字面量将带有该encoding-prefix。若其中一个string-literal没有encoding-prefix，则会被视为与另一个操作数拥有相同encoding-prefix的string-literal处理。如果UTF-8 string literal token与wide string literal token相邻，则程序是ill-formed。其他所有拼接操作均为条件支持，其行为由实现定义。[注：该拼接是一种解释操作，而非转换操作。由于该解释发生在翻译阶段6（此时字符串字面量的每个字符都已被转换为对应字符集中的取值），因此字符串字面量的初始原始性不会对拼接的解释或合法性产生影响。
—注结束]

问题解答 #

• 首先，wchar_t 类型宽字符串的编码规则、编码单元长度均为实现定义：Windows 平台下通常为2字节的UTF-16编码，Linux 平台下通常为4字节的UTF-32编码，部分老旧平台甚至存在其他自定义编码规则；而 UTF-8 字符串的编码规则固定为UTF-8，编码单元长度固定为1字节，两类字符串在翻译阶段5转换完成后的底层存储结构、编码逻辑完全不兼容，不存在通用的拼接解释基础。
• 其次，标准委员会将该类拼接直接定义为 ill-formed（编译期非法）而非条件支持，是为了避免严重的可移植性问题：如果放开为实现定义行为，同一份代码在不同平台、甚至同一平台的不同编译配置下，可能产生完全不同的运行结果，甚至出现内存访问异常，这种完全不可控的行为没有开放给实现自定义的价值，直接定为非法可以在编译期提前捕捉到这类逻辑错误。
• 你提到的注释内容，本质是为了说明拼接阶段不会再回退解析源码的原始字符序列，仅基于阶段5转换完成后的编码值处理，这一逻辑和该类拼接直接定为非法并不冲突：正因为两类字符串转换完成后的编码值完全不兼容，没有统一的拼接规则可以适用，所以不需要进入“条件支持”的判断分支，直接判定为非法即可。

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