I think this advice is incomplete In general, I don't like to try risky new things in prod right away. Maybe I'll write some throwaway code or a test that uses

I think this advice is incomplete In general, I don't like to try risky new things in prod right away. Maybe I'll write some throwaway code or a test that uses the new thing. (This is how I started playing with ranges) If it's an improvement, I'll leave it in, and as I figure out how to write clean code or fix the bugs with it, I'll start considering it in prod. This is a useful trick! Also consider the alternative (eg in this case you can just write class functions on your type or use existing libraries) If you get reasonable push back, don't use it. But I've seen it used in end seemed like sensible places in a production codebase and wouldn't say "never do this." The limits idea at the end seems fine, for example. (The rust language ergonomics can be a good guide: try to balance "applicability", "power", and "context dependence". [1] In the case of limits it is not very powerful, it's just a little syntax sugar. Seems ok. I would say the from_string code has a few more footguns) [1] https://blog.rust-lang.org/2017/03/02/lang-ergonomics.html https://blog.rust-lang.org/2017/03/02/lang-ergonomics.html