编写的std::expected便捷封装宏是否正确？存在哪些风险？

你的生命周期假设是否正确？ #

不完全正确。

你使用的({ ... })是GCC/Clang的语句表达式扩展，内部定义的res变量生命周期仅局限于该语句表达式的执行过程。当CHECK(f())所在的赋值表达式完成求值后，res会立即被销毁：

• 如果接收返回值的是值类型（比如你的例子中Foo foo = CHECK(f());），res.value()会返回Foo的拷贝，foo持有独立的对象，不会有问题；
• 如果用引用接收返回值（比如auto& foo = CHECK(f());），res.value()返回的是对res内部存储的Foo的引用，res销毁后这个引用会变成悬垂引用，触发未定义行为。

该宏的潜在出错场景 #

1. 编译器兼容性问题 #

({ ... })是GNU编译器扩展，不属于标准C++语法。如果代码需要在MSVC等不支持该扩展的编译器上编译，会直接报错。

2. 引用悬垂风险 #

如上文所述，若使用引用绑定CHECK宏的返回值，会因为res的生命周期结束而导致悬垂引用，引发未定义行为。

3. 错误类型不匹配 #

如果当前函数返回的std::expected的错误类型，与被调用函数（比如f()）的错误类型不一致，return std::unexpected{res.error()}会因为类型不匹配编译失败。例如：

// 当前函数返回错误类型为std::error_code
std::expected<int, std::error_code> bar() {
    // f()返回错误类型为std::string，此处编译失败
    Foo foo = CHECK(f());
    // ...
}

4. 宏参数的逗号解析问题 #

宏的参数解析会以逗号为分隔符，如果expr是包含逗号的表达式（比如CHECK(f(1, 2))），宏会错误地将f(1作为第一个参数，2)作为第二个参数，导致编译错误。必须用额外括号包裹表达式（CHECK( (f(1, 2)) )）才能避免，但这增加了使用成本。

5. 无法适配constexpr函数 #

标准C++不允许在constexpr函数中使用语句表达式扩展，即便GCC有非标准支持，也无法保证跨编译器的兼容性。如果你的函数是constexpr，使用该宏会直接编译失败。

6. 不支持void类型的std::expected #

C++23支持std::expected<void, E>类型，此时res.value()是void类型，无法作为语句表达式的返回值（语句表达式要求最后一行是可求值的表达式），宏会编译失败。

7. 自定义错误处理受限 #

如果需要对错误信息进行额外处理（比如包装、转换），该宏硬编码的return std::unexpected{res.error()}无法满足需求，灵活性不足。

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