创建功能门控枚举变体是不好的做法吗？ [关闭]

Question

如果库 crate 定义了一个具有功能门控变体的

enum

怎么办？

#[non_exhaustive]
enum Foo {
    A,
    B,
    #[cfg(feature = "some-feature")]
    Gated,
}

这是一种天真的尝试，允许

enum Foo

支持带有

Gated

变体的可选功能，同时还允许不需要该功能的客户选择退出与之相关的成本（通过禁用板条箱功能

 some-feature

).

与此相关的潜在危险和/或成本是什么？

Answer 1

如果枚举是 not 标记为

#[non_exhaustive]

，这可能会导致二进制箱一侧出现意外且无法有效解决的破损。

想象一下以下情况：

• 你的图书馆

  foo

  导出这个枚举：

pub enum Foo {
    A,
    B,
    #[cfg(feature = "some-feature")]
    Gated,
}

• Library

  bar

  依赖于

  foo

  without 功能和匹配

  foo::Foo

  ，处理

  Foo::A

  和

  Foo::B

  并忽略

  Foo::Gated

  ，因为它在这个配置中不存在。
• 二进制

  baz

  同时依赖于

  bar

  和

  foo

  ，with特征。

然后，

bar

本身工作正常，但尝试构建

baz

将失败，因为功能将跨依赖树统一，并且当

some-feature

处于活动状态时，

bar

中断。

有人可能会争辩说这是

bar

的错，因为他们必须预测添加的功能（并可能将其重新导出为自己的功能）。