> So .clone() significantly reduces the mental overhead of using rust with a small performance impact? I'm intrigued :)
No, the performance impact will depend on `impl Clone` for the underlying type, the hotness of the code path, and how sensitive to those two variables your code's domain is. It may be extremely expensive.
> Maybe it's harder to reason about the lifetime semantics while also writing code, and works better as a second phase (the de-cloning).
There are cases where assuming `clone` is possible allows for significant architectural and API simplifications at the expense of performance. In those cases, de-cloning will be involved and may produce significant changes.
Sorry, should clarify. .clone() itself isn't inherently unidiomatic when used .
My issue is specifically with how the AI uses it. In AI code, .clone() is almost always used as a brute-force escape hatch
Just like for me as an amateur Rust enjoyer then
So .clone() significantly reduces the mental overhead of using rust with a small performance impact? I'm intrigued :)
Maybe it's harder to reason about the lifetime semantics while also writing code, and works better as a second phase (the de-cloning).
No, the performance impact will depend on `impl Clone` for the underlying type, the hotness of the code path, and how sensitive to those two variables your code's domain is. It may be extremely expensive.
There are cases where assuming `clone` is possible allows for significant architectural and API simplifications at the expense of performance. In those cases, de-cloning will be involved and may produce significant changes.