Yes, that ultimately comes down to how hot the code path is and the asymptotic complexity of the `clone` method itself, which are very much influenced by the nature of your application.
What we're saying is that, in the context of "fast development", it's a beneficial mental model to treat cloning as cheap and expendable, *until proven ot…
Yes, that ultimately comes down to how hot the code path is and the asymptotic complexity of the `clone` method itself, which are very much influenced by the nature of your application.
What we're saying is that, in the context of "fast development", it's a beneficial mental model to treat cloning as cheap and expendable, *until proven otherwise*.
Perhaps a direct corollary here is that it would generally be a good idea to design your datastructures *such that* clones are as cheap as possible (e.g. by making it shallow), since `Clone` is such an integral part of Rust ownership model. That way you set it up so you can use clone "guilt-free" to satisfy the borrow checker, while relegating the deep copy to an explicit method for those (much rarer) cicurmstances that needs it.
Yes, that ultimately comes down to how hot the code path is and the asymptotic complexity of the `clone` method itself, which are very much influenced by the nature of your application.
What we're saying is that, in the context of "fast development", it's a beneficial mental model to treat cloning as cheap and expendable, *until proven otherwise*.
Perhaps a direct corollary here is that it would generally be a good idea to design your datastructures *such that* clones are as cheap as possible (e.g. by making it shallow), since `Clone` is such an integral part of Rust ownership model. That way you set it up so you can use clone "guilt-free" to satisfy the borrow checker, while relegating the deep copy to an explicit method for those (much rarer) cicurmstances that needs it.