Elaborate on deriving vs implementing Copy
#129938
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @thomcc (or someone else) some time within the next two weeks. Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (
|
rustbot
added
S-waiting-on-review
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
|
@bors r+ rollup |
bors
added
S-waiting-on-bors
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this pull request
Sep 5, 2024
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.
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Sep 5, 2024
…iaskrgr Rollup of 6 pull requests Successful merges: - rust-lang#129529 (Add test to build crates used by r-a on stable) - rust-lang#129624 (Adjust `memchr` pinning and run `cargo update`) - rust-lang#129720 (Simplify DestProp memory management) - rust-lang#129796 (Unify scraped examples with other code examples) - rust-lang#129891 (Do not request sanitizers for naked functions) - rust-lang#129938 (Elaborate on deriving vs implementing `Copy`) Failed merges: - rust-lang#129471 ([rustdoc] Sort impl associated items by kinds and then by appearance) r? `@ghost` `@rustbot` modify labels: rollup
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this pull request
Sep 5, 2024
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.
This was referenced Sep 5, 2024
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Sep 5, 2024
…iaskrgr Rollup of 8 pull requests Successful merges: - rust-lang#128820 (fix: get llvm type of global val) - rust-lang#129028 (`impl_trait_overcaptures`: Don't worry about uncaptured contravariant lifetimes if they outlive a captured lifetime) - rust-lang#129471 ([rustdoc] Sort impl associated items by kinds and then by appearance) - rust-lang#129706 (Rename dump of coroutine by-move-body to be more consistent, fix ICE in dump_mir) - rust-lang#129720 (Simplify DestProp memory management) - rust-lang#129796 (Unify scraped examples with other code examples) - rust-lang#129938 (Elaborate on deriving vs implementing `Copy`) - rust-lang#129973 (run_make_support: rename `Command::stdin` to `stdin_buf` and add `std{in,out,err}` config helpers) r? `@ghost` `@rustbot` modify labels: rollup
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Sep 5, 2024
…iaskrgr Rollup of 8 pull requests Successful merges: - rust-lang#128820 (fix: get llvm type of global val) - rust-lang#129028 (`impl_trait_overcaptures`: Don't worry about uncaptured contravariant lifetimes if they outlive a captured lifetime) - rust-lang#129471 ([rustdoc] Sort impl associated items by kinds and then by appearance) - rust-lang#129706 (Rename dump of coroutine by-move-body to be more consistent, fix ICE in dump_mir) - rust-lang#129720 (Simplify DestProp memory management) - rust-lang#129796 (Unify scraped examples with other code examples) - rust-lang#129938 (Elaborate on deriving vs implementing `Copy`) - rust-lang#129973 (run_make_support: rename `Command::stdin` to `stdin_buf` and add `std{in,out,err}` config helpers) r? `@ghost` `@rustbot` modify labels: rollup
rust-timer
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Sep 5, 2024
Rollup merge of rust-lang#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.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Copyif the bits it is storing can beCopy, and in the case of a generic struct that can only be the case ifT: 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 ofT. And if you aren't, it may be the case that your own bits can be copied regardless of whether the bits ofTcan 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
PhantomDataback link is going to just work or need some extra stuff, but I figured someone else probably could just tell.