The `TorClient` type is "implicitly Arc": it has a Clone with Arc-like semantics, which copies each of a wide variety of internal objects. It would IMO be cleaner and more reasonable, IMO, to make its constructors return an `Arc<TorClient>`. This would also enable us to have a weak pointer to a TorClient, which would be useful in some RPC contexts. (We made a similar change with channels and circuits a while ago.) This would break existing code using the arti-client crate, unless we some up with some hack so that it doesn't. ### Benefits - `Arc<TorClient>::clone` will be cheaper than `TorClient::clone`, since it won't have to copy as much. - It will be possible to use the whole `Arc` API to work with `TorClient`s. This includes creating `Weak<TorClient>` for RPC and for background tasks. (I suspect it will also be useful for shutdown.) - The semantics of cloning an `Arc<TorClient>` will be more clear than those of cloning a `TorClient`. ### Costs This change would require changing nearly all existing code that uses `arti-client`. ### Alternatives - We could create a new set of APIs that create an `Arc<TorClient>`, and deprecate the existing APIs instead. - We could well defer this until we have thought more about the relationship between `TorClient`, `InertTorClient`, shutdown, deferred-bootstrap, isolated TorClients, etc. It may be that a larger refactoring is warranted.