Rust官方宣布启动函数重载实验，一个特性打通 C++ 互操作最后一公里
内容提要
Rust官方语言团队在Nightly版本中启动函数重载实验，旨在解决Rust调用C++重载函数时的命名问题。实验引入临时语法`#[rustc_splat]`，允许重载函数像普通函数一样调用，如`hypot(2.0, 3.0, 6.0)`，无需元组包装。该特性基于Rust-C++互操作计划，由谷歌资助，目前仍不完整，可能变更。团队提出四条设计公理，未来或推出`#[overload]`属性简化调用。
延伸解读
实验性质与稳定性风险
该特性目前仅在Nightly版本中可用，且官方明确表示它是不完整的，可能随时更改或移除。这意味着它不适合在生产环境中使用，开发者若尝试体验，需注意编译器版本更新可能导致代码失效。此外，rustdoc展示和函数指针支持等周边功能也尚不稳定，遇到问题时应升级到最新Nightly版本。
设计公理背后的权衡
Rust团队为函数重载划定了四条设计公理，强调重载应是现有语义的自然延伸，而非照搬C++规则。例如，他们明确不会采用C++的实参依赖查找（ADL），因为不同语言的重载规则可能冲突。这暗示未来的重载特性将优先保证Rust自身的一致性，必要时要求开发者显式转换或消歧，而非追求与C++完全一致的行为。
对互操作工具链的潜在影响
该实验由Rust-C++互操作计划推动，旨在解决绑定生成工具（如Crubit、cxx、autocxx、bindgen）在处理C++重载函数时的命名难题。如果特性成熟，这些工具可能无需为每个重载生成唯一名称，从而减少C++ API迭代对Rust绑定的破坏性影响。不过，目前实验仍处于早期，工具链的适配尚需时日。
Q&A
Rust官方为什么启动函数重载实验？
Rust官方启动函数重载实验是为了解决Rust调用C++重载函数时的命名问题，实现更顺畅的互操作。该实验由Rust-C++互操作计划推动，谷歌资助。
Rust中函数重载的现状是什么？
在稳定版Rust中，没有直接支持函数重载，但可以通过元组加trait的方式模拟，例如hypot((2.0, 3.0, 6.0))，或者通过运算符重载（如实现Add trait）来实现特定场景的重载。但这些方式不够通用和自然。
splat实验中的#[rustc_splat]属性有什么作用？
#[rustc_splat]属性允许将元组参数在调用时“打散”传入，使得重载函数可以像普通函数一样调用，例如hypot(2.0, 3.0, 6.0)，而不需要显式地写成hypot((2.0, 3.0, 6.0))。它只是语法糖，不改变类型推导和检查机制。
Rust团队为函数重载实验提出了哪些设计公理？
Rust团队提出了四条设计公理：1. 保持Rust的“温和”，重载应是现有语义的自然延伸；2. 让调用重载的FFI函数变得简单；3. 维护外语（如C++）一方的可维护性，C++库重载变化不应给Rust调用方带来更大破坏；4. 选出大多数开发者都会预期的那个重载，避免意外。
splat实验目前有哪些限制？
splat实验目前仅限Nightly版本，且可能随时变更或移除；语法本身不优雅，只是临时方案；rustdoc展示支持刚合并，参数显示为省略号；函数指针支持近期才合并，可能遇到ICE；标准库层面的变参实验还在推进中。
Rust团队未来计划如何实现函数重载？
Rust团队设想未来通过#[overload]属性，让开发者直接定义重载函数，编译器自动处理trait、元组和splat等细节，使调用外部重载函数像调用普通Rust函数一样自然。但目前倾向于将重载能力限制在extern代码块内。
Rust调用C++重载函数时，旧写法有什么问题？
旧写法需要将参数打包成元组，例如hypot((2.0, 3.0, 6.0))，这增加了调用时的繁琐和违和感。此外，C++库新增重载时，Rust绑定需要手动改名，可能导致破坏性变更。
splat实验的调用解析流程是怎样的？
splat实验不改变类型匹配与分派的核心逻辑，只是改变了参数从调用方传递到trait实现的方式。调用时，参数被“打散”传入，但底层仍然通过trait实现进行分派。
