> 在我使用移动和系统编程（例如 Linux）的经验中，必须使用对象作为类型的变体类型并不常见。你不能使用没有的东西，所以你只能适应你已有的工具。在我使用 C++ 的时候，团队经常编写在逻辑上包含多个变体的类型。然而它们被表示为产品类型，因此有空间开销，并且使用起来容易出错，不便于操作。和类型是改变游戏规则的。看看任何 Rust 项目，你会发现到处都是带有数据的枚举。它们只是建模问题的构建块，就像产品类型一样。一种缺少它们的语言对我来说就像一种没有产品类型的语言一样奇怪。在经历了10年主要使用 C++11 和 C++14 后，仅凭这一点，我再也不想回到 C++ 了（尽管如文章中所述，还有其他原因）。> 错误类型可能是这种类型最流行的变体。已经有几个库可用，它们将成为 C++ 标准的一部分。再次强调，性能和易用性如何？
源讨论从 C++ 转到 Rust原帖 275 条评论 · 导入时统计在API设计或数据结构中，需要使用对象作为类型的变体类型在我的经验中并不常见，尤其是在移动和系统编程（例如Linux）方面。我认为我真正需要使用它们的情况只有几次。 错误类型可能是这种类型的最常见形式。有几个可用的库，并且它们将成为C++标准的一部分。 这是Rust社区将一个次要功能夸大为改变游戏规则的新奇事物的一个例子。
完整原文把你的经验，加入这段讨论。
不是要贬低和类型的价值（当然和类型并不特定于Rust），但我认为产品类型属于数据库/配置，而不是硬编码。
完整原文我刚刚检查了旧版Rust经典“ripgrep”在github上的代码。 在matcher.rs中，枚举被用作穷人的OOP。我看到几个match表达式，然后对每个匹配的类型调用相同的函数。 searcher/mod.rs是一个错误定义。 glob.rs包含一个可以再次用OOP或策略模板实现的策略枚举。 json.rs的用法可以建模为一个单一的类。 core/app.rs更复杂，但可以建模为一系列结构体，将枚举映射到任何类型。或者使用std::variant。或者使用OOP。 我查看了所有实例，没有看到任何改变游戏规则的东西。这是一种不错的语法，应该有非常好的性能，但这些习惯用法太底层了，无法改变任何游戏。
完整原文尊重不同观点，分享具体经验。
登录后即可发帖、评论、转发和引用。