Rust库作者：支持128位时如何配置#![recursion_limit]？

背景 #

我是sosecrets-rs库的作者，正在实现RTSecret<T, MEC: typenum::Unsigned>类型——它代表一种秘密值，当内部的暴露次数计数器ec超过类型参数MEC对应的运行时无符号整数值时，会返回Err或触发panic。

之前我借助社区帮助写了一个声明式宏impl_choose_int!(...)，通过枚举方式为1到64位的类型级无符号整数实现了ChooseInt trait：

trait ChooseInt {
    type Output;
}

现在我把这个宏扩展到了128位，以支持潜在的128位指针宽度架构（这是硬性要求，暂不讨论必要性）。

问题 #

为了让编译器处理128位扩展后的宏展开，我在代码顶部加了#![recursion_limit = "256"]，否则会触发递归超限错误。现在我想问：
作为库作者，我应该在模块级别设置这个递归限制声明吗？这么做会对下游用户产生什么影响？

解答 #

是否应该在模块级别设置？ #

不建议在库的根 crate 或公开模块设置全局递归限制，更推荐把递归限制的设置缩小到仅需要它的模块内部——比如把#![recursion_limit = "256"]加在定义impl_choose_int!宏和相关实现的私有模块上，而非整个库的根。

这种局部设置的方式，只会让编译器在处理该模块时临时提升递归限制，不会影响用户代码的其他部分，是更稳妥的做法。

对下游用户的影响 #

如果在库的全局范围设置递归限制，会带来以下问题：

• 冲突风险：如果用户自己的代码或依赖的其他库也设置了不同的递归限制值，会触发编译冲突——Rust不允许同一编译单元存在多个全局递归限制设置。
• 不必要的性能开销：用户的代码可能不需要这么高的递归限制，全局提升会让编译器在处理用户代码时消耗更多内存、延长编译时间，甚至可能掩盖用户自身代码中的递归问题（比如无限递归的宏）。
• 编译稳定性隐患：虽然256不算极端值，但过高的递归限制可能导致编译器处理复杂代码时出现栈溢出或编译缓慢的情况，给用户带来不必要的编译负担。

替代优化方案 #

1. 模块级局部设置：将递归限制仅作用于宏实现所在的模块，示例如下：

#[recursion_limit = "256"]
mod choose_int_impls {
    // 这里存放impl_choose_int!宏和对应的ChooseInt trait实现代码
}

2. 优化宏逻辑：尝试重构impl_choose_int!的实现方式，减少展开时的递归深度。比如用迭代式宏展开替代递归式，或者借助typenum库自带的类型运算能力减少手动枚举的次数，从根源上降低对递归限制的依赖。

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