3.3.5 该不该定义扩展 Trait？

译文 · 基于 Comprehensive Rust

原文链接: https://google.github.io/comprehensive-rust/idiomatic/leveraging-the-type-system/extension-traits/should-i-define-an-extension-trait.html

3.3.5 该不该定义扩展 Trait？

在什么场景下应优先选择扩展 trait 而非自由函数？

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

// Copyright 2025 Google LLC
// SPDX-License-Identifier: Apache-2.0
pub trait StrExt {
    fn is_palindrome(&self) -> bool;
}

impl StrExt for &str {
    fn is_palindrome(&self) -> bool {
        self.chars().eq(self.chars().rev())
    }
}

// vs

fn is_palindrome(s: &str) -> bool {
    s.chars().eq(s.chars().rev())
}

扩展 trait 的主要优势是易于发现。

• 可发现性： 扩展方法比自由函数更容易发现。语言服务器（如 rust-analyzer）会在你于外来类型实例后输入 . 时建议它们。

• 方法链： 扩展 trait 在人体工学上的一大胜利是方法链。这是 Iterator trait 的基础，允许流畅调用如 data.iter().filter(...).map(...)。用自由函数实现会繁琐得多（map(filter(iter(data), ...), ...)）。

• 泛型与 dyn： Trait 可用作泛型中的 trait 约束，或作为 dyn Trait 的一部分，而自由函数不一定能用于泛型上下文。

• API 内聚： 扩展 trait 有助于打造内聚的 API。若你为外来类型有多个相关函数（如 is_palindrome、word_count、to_kebab_case），把它们归入单个 StrExt trait 通常比让用户导入多个自由函数更干净。

• 权衡： 尽管有这些优势，为单个简单函数定制扩展 trait 可能过头。两种做法都需要额外导入，而熟悉的方法语法未必能证明完整 trait 定义的样板代码是值得的。