I would like to propose a somewhat alternative mechanism of achieving the same goal.
An attribute that be added to a crate/module/function which explicitly lists what types should be implicitly cloned in the context of that attribute. i.e. #![AutoClone(Arc, Rc)]
There’s no ImplicitClone trait, and nothing is declared on the type itself. This allows the caller to decide what they view as expensive or cheap, rather then the struct author deciding - because different consumers have different opinions here.
There’s an explicit list of types which are being opted in in the calling scope, which means you don’t need to worry that other types will implicitly be cloned which may be expensive. The crate author can decide explicitly, and their decisions don’t leak out into their dependees.
This doesn’t bifurcate the language; you have to be explicit about what you’re applying this to, and as there’s nothing special on the type-defining side, you don’t need to worry about half of the ecosystem not using a marker trait.
Also, if someone decides they want to undo this change in their crate, it should be possible to write some code which would re-write the source to remove the attribute and make the implicit clones explicit again.
My particular motivation here is that I use rust in higher-level contexts with a lot of Futures, and absent async/await with borrowing, I have to clone a lot of Arcs into Futures. I personally don’t care about the cost of these Arc clones (they’re much cheaper than the network calls / forks that run in my particular Futures), and I don’t care too much about having to write them, but the number of them I need to read actually makes it harder to read the intent of the code. In these projects, I would happily mark Arc as AutoClone, but I can see why other contexts would find this problematic. So let’s allow the author to decide, in a way that doesn’t force the decision on others?