Rust 大佬为 AI 破例：十年来第一次，他说“命名参数”可以有
内容提要
Rust社区就是否引入命名参数展开争论。Klabnik因AI编程代理降低打字成本而支持命名参数，但反对默认参数。Endler认为现有struct、Option、Default、trait等机制已能替代八成需求，且更类型安全。双方共识：不急于扩充语法，更好的设计源自更好的类型。
延伸解读
AI 编程代理如何改变语言设计权衡
Klabnik 的立场转变并非源于人类程序员的需求变化，而是 AI 编程代理的普及。当代码由 Claude Code 等代理生成时，多打参数名的成本不再由人类承担，而显式参数名能减少代理查阅函数签名的 token 消耗。这提示我们，AI 时代语言设计的成本收益分析正在被重新计算，但 Klabnik 也强调，这一逻辑不适用于默认参数，因为其问题在于信息隐藏而非打字量。
Rust 现有类型系统对参数痛点的覆盖
Endler 指出，Rust 无需新增语法即可解决约八成参数传递需求。通过 struct 打包参数、Option 与 Default 处理可选和默认值、trait 与枚举模拟重载和多态，这些机制零运行时开销且类型安全。例如，将 crop_imm 的四个 u32 参数打包为 Crop 结构体，既获得命名参数的清晰性，又避免函数指针和求值顺序的难题。
命名参数落地面临的语言设计挑战
即便支持命名参数，Klabnik 也列举了多重障碍：Rust 参数本质是模式而非名字，需发明内外名字语法；函数指针和 trait 签名中的参数名如何处理；打乱顺序传参时求值顺序按声明还是书写；参数名成为公开 API 后重命名会破坏兼容性。这些难题意味着，命名参数并非简单的语法糖，而可能引发连锁复杂度。
对开发者的实操启示
这场论战给出的朴素建议是：当函数参数达到五六个时，先问自己这些参数是否本应是一个结构体。Rust 的哲学倾向于将语义外置到类型系统，而非塞进调用语法。使用 struct、Option、Default 和 builder 模式，不仅能模拟命名参数和默认参数，还能让代码更显式、更类型安全，且无需等待语言特性变更。
Q&A
Steve Klabnik 为什么改变了对 Rust 命名参数的立场？
Klabnik 改变立场的主要原因是 AI coding agent 的普及。过去他反对命名参数，是因为多打字的成本由人类承担；但现在代码常由 AI 编写，打字成本不再重要，而显式参数名能降低人类和 AI 的上下文查阅开销。
Matthias Endler 认为 Rust 不需要命名参数，他的主要论据是什么？
Endler 认为 Rust 现有的类型系统（struct、Option、Default、trait、枚举等）已经能以类型安全、零运行时开销的方式解决约 80% 的参数传递痛点。他主张将语义外置到类型中，而不是塞进函数调用语法。
在 Rust 中如何用现有机制模拟命名参数？
可以将参数打包成一个结构体，调用时传入该结构体实例。例如定义 struct Crop { x: u32, y: u32, width: u32, height: u32 }，然后调用 crop_imm(&img, Crop { x: 10, y: 20, width: 200, height: 100 })。这样字段名就是参数名，且顺序任意、有自动补全和文档。
Rust 中如何实现可选参数和默认参数？
使用 Option 类型表示可选参数，结合 Default trait 和结构体更新语法提供默认值。例如定义 #[derive(Default)] struct RequestOptions { timeout: Option<Duration>, ... }，调用时用 RequestOptions { timeout: Some(...), ..Default::default() }。
Klabnik 为什么坚决反对默认参数和可选参数？
Klabnik 认为默认参数和可选参数会导致信息隐藏：调用点上原本应该出现的参数被省略，使得调用约定变得随意，破坏语言简洁性。即使打字成本降低，隐藏信息带来的代价依然存在。
如果 Rust 要加入命名参数，会面临哪些语言设计难题？
主要难题包括：参数本质是模式而非名字，需要发明内部/外部名字语法；函数指针和 trait 签名中参数名如何处理；求值顺序是按声明还是按书写顺序；参数名成为公开 API 后重命名会破坏兼容性，需要别名机制。
Endler 如何用 Rust 现有机制替代函数重载？
Endler 将重载需求分为三类：简便版与完整版用不同函数名（如 connect 和 connect_with_timeout）；接受多种输入类型用 trait 泛型（如 impl AsRef<str>）；不同类型不同行为用 trait 多态。对于多种调用方式，可用枚举加 From/Into 转换。
在 AI 时代，Klabnik 和 Endler 对“多打字”的看法有何分歧？
Klabnik 认为 AI 让打字成本降低，所以可以接受命名参数带来的啰嗦；Endler 则认为打字成本趋近于零后，多写一个结构体来声明语义的代价也被抹平，反而更应让 AI 编写带有完整语义身份的独立结构体，而不是依赖语法糖。
