Skip to content

Clone documentation can be confusing to beginners around "duplication" language #141138

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
Eveheeero opened this issue May 17, 2025 · 2 comments · Fixed by #141215
Closed

Clone documentation can be confusing to beginners around "duplication" language #141138

Eveheeero opened this issue May 17, 2025 · 2 comments · Fixed by #141215
Labels
A-docs Area: Documentation for any part of the project, including the compiler, standard library, and tools C-enhancement Category: An issue proposing an enhancement or a PR with one.

Comments

@Eveheeero
Copy link

Hi, I'm mainly using rust for developing application

I wonder is it safe to impl Clone for Arc<Mutex>

Arc is a frequently used pattern for modifying data in multiple places.

However, if you end up cloning a parent struct that contains an Arc, it's hard to tell that the data inside is the same data without knowing more about the internal structure

For example

#[derive(Clone)]
struct Context {
  things: Object,
  id_to_object: Arc<Mutex<usize, BigObject>>,
}
impl ThreadContext {
  fn add_data(id: usize, obj: BigObject) -> ...;
}
// I cloned ctx to reuse it, but when I call `add_data`, we see that the original ctx also modified
let ctx = old_ctx.clone();

This becomes more likely to happen whenever you wrap it in a parent that implements #[derive(Clone)].

So I thought that struct with Arc<Mutex> shouldn't be able to implement clone as simply as writing #[derive(Clone)].

Is this unsafe? or is it something that users should be aware of?

@rustbot rustbot added the needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. label May 17, 2025
@cuviper
Copy link
Member

cuviper commented May 17, 2025

Arc<T> implements Clone for any T, without restriction. We don't have any mechanism that could exclude Arc<Mutex>, and even if we did, that would be a breaking change.

Cloning Arc is definitely safe in the usual Rust meaning of the term, but you can reasonably argue that this could be surprising in some cases. In fact, it's often recommended style to call Arc::clone(&x) rather than x.clone() even though they mean the same thing, just to make it clear that the underlying type is not cloned. There's no workaround like that for derive(Clone) though.

@fee1-dead fee1-dead added A-docs Area: Documentation for any part of the project, including the compiler, standard library, and tools C-discussion Category: Discussion or questions that doesn't represent real issues. and removed needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. labels May 18, 2025
@fee1-dead
Copy link
Member

The docs for Clone currently says "A common trait for the ability to explicitly duplicate an object."

What would it mean to people new to the language, or have different notions of "duplicating an object" coming from a different programming language?

This is probably a good opportunity to make the documentation clearer and more helpful to describe what exactly Clone is, to prevent people from getting surprised by behaviors like this.

@fee1-dead fee1-dead changed the title Is it safe to impl Clone for Arc/Rc of Mutex/RwLock ? Clone documentation can be confusing to beginners around "duplication" language May 18, 2025
@fee1-dead fee1-dead added C-enhancement Category: An issue proposing an enhancement or a PR with one. and removed C-discussion Category: Discussion or questions that doesn't represent real issues. labels May 18, 2025
jhpratt added a commit to jhpratt/rust that referenced this issue May 31, 2025
…bilee

std: clarify Clone trait documentation about duplication semantics

Closes rust-lang#141138

The change explicitly explains that cloning behavior varies by type and clarifies that smart pointers (`Arc`, `Rc`) share the same underlying data. I've also added an example of cloning to Arc.
@bors bors closed this as completed in fa494d6 Jun 1, 2025
rust-timer added a commit that referenced this issue Jun 1, 2025
Rollup merge of #141215 - xizheyin:issue-141138, r=workingjubilee

std: clarify Clone trait documentation about duplication semantics

Closes #141138

The change explicitly explains that cloning behavior varies by type and clarifies that smart pointers (`Arc`, `Rc`) share the same underlying data. I've also added an example of cloning to Arc.
github-actions bot pushed a commit to rust-lang/miri that referenced this issue Jun 1, 2025
std: clarify Clone trait documentation about duplication semantics

Closes rust-lang/rust#141138

The change explicitly explains that cloning behavior varies by type and clarifies that smart pointers (`Arc`, `Rc`) share the same underlying data. I've also added an example of cloning to Arc.
github-actions bot pushed a commit to model-checking/verify-rust-std that referenced this issue Jun 3, 2025
…bilee

std: clarify Clone trait documentation about duplication semantics

Closes rust-lang#141138

The change explicitly explains that cloning behavior varies by type and clarifies that smart pointers (`Arc`, `Rc`) share the same underlying data. I've also added an example of cloning to Arc.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-docs Area: Documentation for any part of the project, including the compiler, standard library, and tools C-enhancement Category: An issue proposing an enhancement or a PR with one.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants