处理完std::variant全部类型后使用static_assert(false)的合规性与编译问题

场景背景 #

在cppreference的std::visit示例代码基础上，针对std::variant<int, long, double, std::string>的所有类型分支处理完成后，新增了一个else分支，分支内写有static_assert(false)。该代码在GCC 13.1之前版本会触发"static assertion failed"编译错误，新版GCC可正常编译，但部分其他编译器的最新版本仍报错。

1. 根据C++标准，该代码是否应编译通过？ #

答案是应该通过。

根据C++标准中关于常量表达式和不可达代码的规则：如果static_assert所在的代码分支是完全不可达的（即程序运行时永远不会进入该分支），编译器不需要对这个分支里的static_assert进行求值或实例化。

对于覆盖了std::variant所有类型的std::visit分支来说，else分支属于绝对不可达路径——因为variant的存储值必然是其类型列表中的某一种，不可能触发else分支。C20及之后的标准对这类不可达代码的处理有明确规定，即使是C17，标准的精神也支持这种写法的合规性。

2. 若合规，其他编译器厂商是否会修复此问题？ #

大概率会修复。

这类问题属于编译器对标准规则的实现细节差异，GCC 13.1已经完成了对该场景的支持，说明业界对标准的解读已经达成共识。其他主流编译器厂商（比如Clang、MSVC）通常会跟进对齐标准的要求，后续版本中会修复这类兼容性问题。不过具体的修复时间取决于厂商的迭代节奏，无法给出确切时间点。

3. 这是否是实用的编程惯用法？ #

这是一种很实用的防御性编程技巧，核心价值在于：

• 防止遗漏分支：如果后续修改variant的类型列表（比如新增一个类型），但忘记在std::visit中添加对应的处理分支，编译器会立刻触发static_assert报错，强制开发者补充逻辑，避免出现未处理的类型导致运行时问题。
• 代码可读性提示：明确告诉后续维护者，此处已经覆盖了variant的所有可能类型，不存在未处理的分支，减少阅读代码的歧义。

不过要注意，这种写法依赖编译器对不可达代码的正确识别，在未支持的旧版本编译器中会报错，所以使用前需要确认项目的编译器环境是否兼容。另外，也可以通过std::variant_size_v配合static_assert做类似检查，但这种分支内的写法更直观，和业务逻辑结合得更紧密。

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