diff options
| author | Matthias Krüger <matthias.krueger@famsik.de> | 2024-09-05 18:58:56 +0200 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2024-09-05 18:58:56 +0200 |
| commit | 0db3932433e0c2ebafe24ebbbb840b928d39f719 (patch) | |
| tree | 7cbfaf804f02cc8e777d8e03a4306428fa696584 | |
| parent | 9be97ae8e29b99a030a327cdb50e1997a4ff3470 (diff) | |
| parent | e45b53efc0ef0f86df82918720cfae78e295e3ac (diff) | |
Rollup merge of #129938 - chancancode:patch-1, r=thomcc
Elaborate on deriving vs implementing `Copy` I was reading this documentation and this wasn't immediately clear to me. In my mind, it seemed obvious that a type can only claim to be `Copy` if the bits it is storing can be `Copy`, and in the case of a generic struct that can only be the case if `T: Copy`. So the bound added by the derive seemed necessary at all times, and I thought what the documentation was trying to say is that the custom implementation allows you to add _additional bounds_. Of course what it was actually trying to point out is that just because you have a generic parameter `T`, it doesn't necessarily mean you are storing the bits of `T`. And if you aren't, it may be the case that your own bits can be copied regardless of whether the bits of `T` can be safely copied. Thought it may be worth elaborating to make that a bit more clear. Haven't tested/didn't try to figure out how to render this locally. Mainly not sure if the `PhantomData` back link is going to just work or need some extra stuff, but I figured someone else probably could just tell.
| -rw-r--r-- | library/core/src/marker.rs | 15 |
1 files changed, 13 insertions, 2 deletions
diff --git a/library/core/src/marker.rs b/library/core/src/marker.rs index 5654f5aa4b8..d9f197d9510 100644 --- a/library/core/src/marker.rs +++ b/library/core/src/marker.rs @@ -288,8 +288,19 @@ marker_impls! { /// } /// ``` /// -/// There is a small difference between the two: the `derive` strategy will also place a `Copy` -/// bound on type parameters, which isn't always desired. +/// There is a small difference between the two. The `derive` strategy will also place a `Copy` +/// bound on type parameters: +/// +/// ``` +/// #[derive(Clone)] +/// struct MyStruct<T>(T); +/// +/// impl<T: Copy> Copy for MyStruct<T> { } +/// ``` +/// +/// This isn't always desired. For example, shared references (`&T`) can be copied regardless of +/// whether `T` is `Copy`. Likewise, a generic struct containing markers such as [`PhantomData`] +/// could potentially be duplicated with a bit-wise copy. /// /// ## What's the difference between `Copy` and `Clone`? /// |
