对“解析,而非校验”的 Rust 思考
<p>和许多程序员一样,我也觉得 Alexis King 的 文章非常有趣,因为它为一种看似熟悉且重要的编程惯用法赋予了名称——这种惯用法我过去也曾观察并使用过,却从未明确地给它命名。<br><br>本文是对“解析而非验证”模式在 Rust 编程语言中的应用进行的评述(原文使用的是 Haskell)。我尤其关注在 Rust 标准库及其他知名项目中寻找该模式的教学示例。</p><p>这里不再重复原文内容(请先阅读原文!),以下是其核心要点。</p><p>以 Vec 这个经典类型为例,它的 first 方法返回 Option<&T>。为什么?因为一个向量并不保证一定包含元素,那么如果对空向量调用 first 会怎样呢?<br><br>在这种情况下返回 Option 是 Rust 中的惯用做法,并且提供了便捷的语法糖来处理那些返回 Option 的函数结果,从而决定下一步该如何操作。</p><p>那么问题出在哪里呢?</p><p>假设我们有一个从环境变量中读取配置路径的函数,同时强制要求列表不能为空:</p><pre>use anyhow::{Result, ensure}; fn get_configuration_directories() -> Result> { let value = env::var("CONFIG_DIRS").context("无法读取 CONFIG_DIRS")?; let directories: Vec = value…</pre>