Most of your clones are fine, and the advice you have absorbed is aimed at a different problem than the one you have.
Cloning a small string or a small struct is cheap. An allocation and a copy of a few dozen bytes. In a program that is doing anything at all — reading a file, making a request, touching a database — this is invisible. People who tell you never to clone are usually thinking about tight loops and large data, and the advice gets repeated without the context.
So the first question is not stylistic, it is where is it. A clone in a startup path, a config load, or a request handler that runs a thousand times a second on a small string: fine. A clone of a large collection inside a loop that runs a million times: not fine, and you would see it.
Where clone genuinely signals a design problem:
- You are cloning to get around ownership you have not decided on. Two parts of the program both think they own the same thing, and clone lets both pretend. This is the real one.
- You clone a large structure to read one field. That is a signature problem, not an ownership problem.
- You clone inside a loop, from outside it. Usually the value could be borrowed or hoisted.
- You clone and then mutate the copy, and expect the original to change. Now it is a bug, not a cost.
Yours sound like the first category is the risk, not performance.