As the community has gained experience writing Rust, we have found that there is some nonzero cost to pure monomorphization. And to be fair, the other way ("polymorphic inner function inside a monomorphized shell") also has a nonzero cost. So what we're really looking at is a tradeoff problem.
Two ways to approach this are:
- Give the code author the tools to manually opt-in to the polymorphic-in-monomorphic form.
- Make the compiler switch to this form automatically as an optimization.
The momo crate seems like a good tool to address 1, since it's available today, it's minimal, it works, and it matches Rust's "let libraries experiment first" approach.
Separately, it could still be valuable to pursue 2 in parallel, to implicitly optimize to the polymorphic-in-monomorphic form if we can find a good heuristic indicator that applying the optimization is likely to be a net benefit. Who knows, maybe it could even be a good strategy to do this for every applicable function just to reduce the volume of code in intermediate representations even if the compiler decides to re-duplicate the object code at the end.
Related discussions:
- Inner function sugar? (internals, Nov '21)
- Wondering what an example would be of a non-generic inner function mentioned in Rust for Rustaceans (users, Jul '22)
- Non-Generic Inner Functions (blog, Oct '20)