Rust中实现灵活字符串模式匹配的最优方案探讨

我尝试用Rust的Pattern trait配合str.find()写一个更灵活的函数，但直接在参数里用Pattern类型会报错：

use std::str::pattern::Pattern;

fn find_complex(string: &str, pattern: Pattern) -> Option<usize> {
    // 调用原生find前的复杂逻辑
    string.find(pattern)
}

编译错误：

error[E0658]: use of unstable library feature 'pattern': API not fully fleshed out and ready to be stabilized
 --> src/find_zero.rs:3:40
  |
3 | fn find_complex(string: &str, pattern: Pattern) -> Option<usize> {
  |                                        ^^^^^^^
  |
  = note: see issue #27721 for more information

因为官方的Pattern处于不稳定状态，我决定自己实现字符串模式匹配，但纠结于哪种实现更符合Rust风格，下面是两种思路各自的问题：

思路一：为每种模式实现自定义Trait #

pub struct StringMatch<'a> {
    index: usize,
    length: usize,
    value: &'a str
}

pub struct StringQulaifierMatch {
    index: usize,
    length: usize,
}

pub trait StringPattern {
    fn find_in<'a>(self, string: &'a str) -> Option<StringMatch<'a>>;
}

impl StringPattern for char {
    fn find_in<'a>(self, string: &'a str) -> Option<StringMatch<'a>> {
        todo!() // 查找单个字符匹配，返回索引、字节长度和匹配位置的字符串切片
    }
}

impl StringPattern for &str {
    fn find_in<'a>(self, string: &'a str) -> Option<StringMatch<'a>> {
        todo!() // 查找字符串匹配，返回索引、字节长度和匹配位置的字符串切片
    }
}

impl StringPattern for Vec<char> {
    fn find_in<'a>(self, string: &'a str) -> Option<StringMatch<'a>> {
        todo!() // 查找任意字符匹配，返回索引、字节长度和匹配位置的字符串切片
    }
}

impl StringPattern for Vec<&str> {
    fn find_in<'a>(self, string: &'a str) -> Option<StringMatch<'a>> {
        todo!() // 查找任意字符串匹配，返回索引、字节长度和匹配位置的字符串切片
    }
}

impl<F> StringPattern for F 
where F : Fn(&str) -> Option<StringQulaifierMatch> {
    fn find_in<'a>(self, string: &'a str) -> Option<StringMatch<'a>> {
        todo!() // 通过迭代增加字符索引，将&string[index..]传给闭包查找匹配
    }
}

问题：无法为不同签名的闭包实现 blanket impl，而且调用方式是pattern.find_in(string)，不符合Rust中string.find(pattern)的惯用写法，显得别扭。

思路二：用枚举封装所有模式类型 #

pub struct StringMatch<'a> {
    index: usize,
    length: usize,
    value: &'a str
}

pub struct StringQulaifierMatch {
    index: usize,
    length: usize,
}

pub enum StringPattern<'a> {
    Char(char),
    String(&'a str),
    CharList(Vec<char>),
    StringList(Vec<&'a str>),
    Qualifier(Box<dyn Fn(&str) -> Option<StringQulaifierMatch>>)
}

pub trait PatternMatching {
    fn match_pattern<'a>(&'a self, pattern: StringPattern) -> StringMatch<'a>;
}

impl PatternMatching for str {
    fn match_pattern<'a>(&'a self, pattern: StringPattern) -> StringMatch<'a> {
        match pattern {
            StringPattern::Char(char_pattern) => todo!(), // 查找单个字符匹配
            StringPattern::String(string_pattern) => todo!(), // 查找字符串匹配
            StringPattern::CharList(char_list) => todo!(), // 查找任意字符匹配
            StringPattern::StringList(string_list) => todo!(), // 查找任意字符串匹配
            StringPattern::Qualifier(qualifier) => todo!(), // 通过闭包查找匹配
        }
    }
}

问题：需要用match处理所有枚举变体，无法享受泛型单态化的优势——只有实际使用的具体版本才会被编译，导致运行时多态带来的性能开销。

请问哪种实现更符合Rust idiom、更灵活且不易出错？也欢迎其他解决方案！

优先选择Trait-based实现（调整设计细节） #

Trait方案更符合Rust的泛型设计哲学，只要调整几个细节就能解决现有问题：

1. 调整调用方向，符合惯用写法 #

把find_in的调用主体换成字符串，而不是模式。修改Trait定义：

pub trait StringPattern {
    fn find_in<'a>(&self, string: &'a str) -> Option<StringMatch<'a>>;
}

// 为str实现扩展方法，贴合原生调用风格
pub trait StrPatternExt {
    fn find_pattern<'a, P: StringPattern>(&'a self, pattern: &P) -> Option<StringMatch<'a>>;
}

impl StrPatternExt for str {
    fn find_pattern<'a, P: StringPattern>(&'a self, pattern: &P) -> Option<StringMatch<'a>> {
        pattern.find_in(self)
    }
}

这样调用方式就变成"hello".find_pattern(&'l')，和原生str.find()的风格完全一致。

2. 优化闭包的Trait约束 #

如果要支持不同签名的闭包，可以简化返回值约束，比如允许闭包返回Option<(usize, usize)>（索引和长度），替代自定义的StringQulaifierMatch，兼容性更强：

impl<F> StringPattern for F 
where F : Fn(&str) -> Option<(usize, usize)> {
    fn find_in<'a>(&self, string: &'a str) -> Option<StringMatch<'a>> {
        // 迭代字符串的字符边界，逐个传入闭包检查
        for (idx, _) in string.char_indices() {
            if let Some((match_idx, len)) = self(&string[idx..]) {
                let total_idx = idx + match_idx;
                let value = &string[total_idx..total_idx+len];
                return Some(StringMatch { index: total_idx, length: len, value });
            }
        }
        None
    }
}

这样任何返回Option<(usize, usize)>的闭包都能实现StringPattern，不需要额外定义结构体。

Trait方案的核心优势 #

• 符合Rust idiom：沿用标准库泛型+Trait的多态设计思路，开发者上手成本低
• 单态化优化：编译器为每个具体模式类型生成专属代码，无运行时开销
• 扩展性强：其他开发者可以轻松为新类型实现StringPattern，无需修改核心逻辑

枚举方案的适用场景 #

枚举方案并非完全无用，它适合需要动态切换模式的场景，比如从配置文件加载匹配规则、运行时根据用户输入选择模式。但如果你的场景是静态编译时确定模式，枚举的性能开销完全没必要。

替代方案：使用成熟第三方库 #

如果不想重复造轮子，可以直接用regex处理复杂正则匹配，或者strsim处理模糊匹配。这些库经过充分测试，性能和稳定性都有保障。

内容的提问来源于stack exchange，提问作者Gabe_A