rust - 在 From 实现中 panic 是惯用的吗?

标签 rust idioms

文档位于 https://doc.rust-lang.org/std/convert/trait.From.html

Note: This trait must not fail. If the conversion can fail, use TryFrom.

假设我有一个 From 实现:

impl From<SomeStruct> for http::Uri {
    fn from(item: SomeStruct) -> http::Uri {
        item.uri.parse::<http::Uri>() // can fail
    }
}

进一步假设我完全确定 item.uri.parse 会成功。在这种情况下 panic 是惯用的吗?说,用:

item.uri.parse::<http::Uri>().unwrap()

在这种特殊情况下,似乎无法在编译时构造 HTTP URI:https://docs.rs/http/0.2.5/src/http/uri/mod.rs.html#117 .在实际场景中 .uri 是一个关联的常量,所以我可以测试所有使用的值解析。但在我看来,可能还有其他情况,当作者对一段代码的无误性充满信心时,尤其是当这种信心可以在测试中编码时,因此更喜欢 From 的人体工程学尝试从。 Rust 编译器,通常非常严格,不会阻止这种行为,尽管它似乎可以。这让我觉得这是作者被故意允许做出的决定。所以问题是:在这种情况下人们倾向于做什么?

最佳答案

所以一般来说,特征只强制实现者遵守特征中规定的签名和类型。至少这是编译器强制执行的。

除此之外,还有一些契约期望 traits 必须遵守,这样使用这些 traits 的人就不会感到奇怪的惊喜。编译器不检查这些契约;那将是相当困难的。

没有什么能阻止你实现一个特征的所有方法,但是以与特征完全无关的方式,比如实现 Display 特征,然后在 fmt方法实际上并不费心使用 write! 而是,我不知道,删除用户的主目录。

现在回到您的具体案例。如果您的 from 方法不会失败,那么您当然可以使用 .unwrapcannot fail contract for the From trait 的要点是那些依赖 From trait 的人希望能够假设转换将每次。如果您实际上在您自己的 from 实现中感到 panic ,这意味着转换有时不会通过,这与From 特征。

关于rust - 在 From 实现中 panic 是惯用的吗?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/69408253/

相关文章:

arrays - Rust 中 array::len 的运行时复杂度是多少?

rust - 在 Rust 中运行时初始化的全局常量?

python - 列表的 get() 的惯用 python 等价物是什么?

python - 在 Python 中填充字典的更惯用的方法

java - 断言可迭代的每个元素都匹配给定匹配器的惯用 Hamcrest 模式是什么?

java - 使用辅助类使 JavaBean 的使用更加方便——这是某种习惯用法吗?

rust - 包含对 Rust 中文件的引用的结构无法借用

module - `alloc::rc::Rc` 和 `std::rc::Rc` 有什么区别?

bash - 惯用的 bash : set default value for variable

rust - 如何根据功能标志有条件地执行模块级 doctest?