Aaryan-Kapoor/english-rs

把它当作一个做工不错的学习实验或教学案例来试，不要指望用它在生产文档里批量查英文语法。english 类型库与 englishc 散文检查器最好分开评估。

解决什么问题

假设你在改一段英文，想把“He are ready”“me and my brother goed”这类错误像编译器报错一样精确标出来，而不是像拼写检查那样只画条模糊的波浪线。反过来，你在写 Rust，想让编译器检查程序输出的句子里主谓是否一致。englishc 读取普通文本，按 rustc 的诊断格式（错误码、源码位置）报告语法问题，并在答案唯一时提供 --fix。english 库则反过来：用宏把句子拆成带类型的词，一句英语要么通过类型检查，要么编译失败。两种流程都把原本靠人记住的语法规则变成了一次显式、可报告的检查。

有什么不同

有意思的是机制本身。english! 先把输入按句号、感叹号、问号切句，识别主语（代词、指示词、限定词加单个名词，或持有 Noun、Person、Pronoun 的变量），再用 const fn 把动词拼写归类成基础形式、-s 形式、am/is/are、was/were、无标记过去式或情态动词。分类结果变成 const generic 类型，Verb::<BaseForm>::agrees_with 等方法对主语要求不同的 Takes* trait bound，于是主谓一致成了 trait 约束，而不是一张查表。代词持有先行词共享借用，借用检查器会拒绝比名词活得更久的代词。宏之外，动词变形由词形计算，They.past("go") 输出 went，Noun::new("mouse").plural() 输出 mice，不必背不规则形式表。

代价是覆盖面。宏只认有限的主语形态，只在 .、!、? 处切句，较长、带修辞或嵌套的句子很可能超出它能处理的范围；englishc 也只修答案明确的情形。它展示的是类型系统如何建模语法，而不是一个通用英语解析器。

谁值得试

合适的人：对 const generics、trait bound 和借用检查好奇的 Rust 开发者，以及想找生动案例讲解“用类型编码规则”的老师；写检查器或诊断界面的人也能从 rustc 风格报错里借鉴排版。不合适的人：想在规模上检查论文、README 或营销文案的人，因为宏的句子语法和 englishc 的修复能力都是有意收窄的。工作区没有外部依赖，方便阅读和改造，这一点很适合学习场景。

使用条件与边界

根据记录快照，项目才创建 1 天。README 节选展示了一个聚焦、无依赖的工作区，但没有给出广泛的兼容性说明。构建浏览器 playground 需要 wasm32-unknown-unknown target，跑测试和 CLI 则不需要。宏的输入是 Rust 词法的子集，因此书写上要遵守空格约定（示例中写成 'm、don 't），可识别的主语形态也有限，用之前先确认你的句子是否在这个子集里。现有材料也没有证明 englishc 有庞大的规则集或有公开的准确率评估。

HotRepo 点评

HotRepo 的新项目榜（Rust）在 2026-10-27 记录到 #18、总计 104 星；这只是单日快照，不是每日增量，不足以判断长期热度。投入时间前，先对照 README 中的示例和 playground 的示例程序，确认你关心的句子形态是否在支持范围内。

项目源码与说明