为何boost::outcome::result禁止值类型与错误类型相同？

我在实现一个内部JSON解析/验证函数时，尝试返回boost::outcome::result<std::string, std::string>类型——成功时返回解析出的ID字符串，失败时返回详细的错误描述字符串，却发现该类型明确禁止值类型与错误类型使用同一类型。虽然boost已经提供success()和failure()函数来消除歧义，但这种限制还是让人疑惑：明明可以显式标记结果，为什么要做这种强制限制？

核心原因分析 #

1. 从根源避免语义歧义

虽然success()和failure()能显式区分结果类型，但在一些隐式场景下，编译器依然无法判断字符串的语义。比如直接传递字符串字面量给接受result<string, string>的函数，或者进行模板参数推导时，编译器没有足够的信息区分这是成功值还是错误值。禁止同类型可以从类型层面彻底杜绝这种模棱两可的情况，强制开发者明确语义边界。

2. 引导更清晰的代码设计

boost::outcome的设计初衷之一是通过类型系统强化错误处理的清晰度。成功的ID字符串和错误描述字符串虽然类型相同，但语义完全不同。强制要求两者类型不同，本质是在引导开发者用更具表现力的方式建模——比如用包装结构体区分两者，让代码意图一目了然，后续维护成本更低。

3. 简化库的实现逻辑

如果允许值类型与错误类型相同，库内部需要处理大量额外的歧义场景：比如构造函数的重载解析、状态判断的边界情况、赋值操作的语义区分等。禁止同类型可以简化库的实现逻辑，减少潜在的bug，同时让库的行为更可预测。

实用替代方案 #

1. 用包装结构体区分语义（推荐）

给两种字符串赋予明确的语义类型，既解决类型冲突，又让代码可读性大幅提升：

struct ParsedId { std::string value; };
struct ErrorMessage { std::string value; };

boost::outcome::result<ParsedId, ErrorMessage> parse_json_id(const std::string& json);

调用者看到返回类型就能立刻明白，ParsedId是成功结果，ErrorMessage是错误信息，完全不需要额外注释。

2. 使用std::error_code作为错误类型

如果错误可以提前归类，用std::error_code作为错误类型是更标准的做法：

boost::outcome::result<std::string, std::error_code> parse_json_id(const std::string& json);

后续可以通过error_code映射到对应的错误描述字符串，还能兼容标准库的错误处理机制。

3. 可选：用std::optional搭配错误输出参数

如果不想引入新类型，也可以用std::optional返回成功值，错误描述通过输出参数传递：

std::optional<std::string> parse_json_id(const std::string& json, std::string& error_msg);

这种方式适合简单场景，但可读性不如result模式。

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