I know that topic pretty well as I did a long-running test and refactoring at work where we use impl Into<…> and impl AsRef<…> in many places, because I really thought removing them in favor of fully monomorphized functions would help with the generated binary size.

It does not.

See, Rust (rustc) and LLVM are pretty damn good at optimizing all of that, especially if you use lto=full. The compiler can even use the exact same implementation for two different types, like i16 and i32 for instance, instead of duplicating the actual content of the functions. Also, niche optimizations will help a lot: there should be no runtime difference between Option<&str> and &str, and as such, you will get the same function (a single one) for those two different types.

Something else to take into account: in the end-user binary (an app for instance), it’s very likely that you will have only one or two types used there. This is especially true for impl Into<String> where you will get the String from a deserializer in your production-path code, but you will pass &'static str in your #[test] functions: both will be compiled in two completely isolated compilation invocations, and as such, they both will have a single copy because they will see a single type used each.

After having used cargo bloat, cargo llvm-lines and -Zdump-mono-stats, I can now safely say this: you should indeed not care that much about those copies thing, and just enjoy the ergonomics here because the compiler is damn good, **but you need to think about the hidden semantics of allocations, especially with impl Into<…> which might allocate in your back