-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
docs(marker/copy): provide example for &T
being Copy
#75049
Conversation
In the current documentation about the `Copy` marker trait, there is a section about "additional implementors", which list additional implementors of the `Copy` trait. The fact that shared references are also `Copy` is mixed with another point, which makes it hard to recognize and make it seem not as important. This clarifies the fact that shared references are also `Copy`, by mentioning it as a separate item in the list of "additional implementors".
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @kennytm (or someone else) soon. If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes. Please see the contribution instructions for more information. |
Feel free to update this PR instead of making a new one, I think it would be nice to keep the discussion in one place. |
In the current documentation about the `Copy` marker trait, there is a section with examples of structs that can implement `Copy`. Currently there is no example for showing that shared references (`&T`) are also `Copy`. It is worth to have a dedicated example for `&T` being `Copy`, because shared references are an integral part of the language and it being `Copy` is not as intuitive as other types that share this behaviour like `i32` or `bool`. The example picks up on the previous non-`Copy` struct and shows that structs can be `Copy`, even when they hold a shared reference to a non-`Copy` type.
&T
is also Copy
&T
being Copy
Co-authored-by: Joshua Nelson <joshua@yottadb.com>
Co-authored-by: Joshua Nelson <joshua@yottadb.com>
So ironic that the ghost emoji has disappeared. 😆 But, it is now back! 😃 |
No problem :) Maybe @poliorcetics is interested in reviewing the doc change? |
I'll have a look later. :) |
Co-authored-by: Poliorcetics <poliorcetics@users.noreply.github.com>
Code blocks in doc comments are compiled and run, so we show `Copy` works in this example. Co-authored-by: Poliorcetics <poliorcetics@users.noreply.github.com>
Looks good to me, thanks ! I don't have the right to |
@poliorcetics Thank you for your swift review! I really appreciate it! ❤️
|
Oh yeah didn't see it sorry. Adding it above too is a good idea ! |
This adds another `derive` for a `Copy`able struct, so that we are consistent with `derive` annotations.
@poliorcetics cc @jyn514 Sorry, for the late response. All the necessary changes from your review are now present. |
@bors r=poliorcetics rollup |
📌 Commit 522d177 has been approved by |
docs(marker/copy): provide example for `&T` being `Copy` ### Edited 2020-08-16 (most recent) In the current documentation about the `Copy` marker trait, there is a section with examples of structs that can implement `Copy`. Currently there is no example for showing that shared references (`&T`) are also `Copy`. It is worth to have a dedicated example for `&T` being `Copy`, because shared references are an integral part of the language and it being `Copy` is not as intuitive as other types that share this behaviour like `i32` or `bool`. The example picks up on the previous non-`Copy` struct and shows that structs can be `Copy`, even when they hold a shared reference to a non-`Copy` type. ----------------------------------------- ### Edited 2020-08-02, 3:28 p.m. I've just realized that it says "in addition to the **implementors listed below**", which makes this PR kind of "wrong", because `&T` is indeed in the "implementors listed below". Maybe we can instead show an example with `&T` in the [When can my type be Copy](https://doc.rust-lang.org/std/marker/trait.Copy.html#when-can-my-type-be-copy) section. What I really want to achieve is that it becomes more obvious that `&T` is also `Copy`, because, I think, it is very valuable to know and it wasn't obvious for me, until I read something about it in a forum post. What do you think? I would create another PR for that. **Please feel free to close this PR.** ----------------------------------- ### Original post In the current documentation about the `Copy` marker trait, there is a section about "additional implementors", which list additional implementors of the `Copy` trait. The fact that shared references are also `Copy` is mixed with another point, which makes it hard to recognize and make it seem not as important. This clarifies the fact that shared references are also `Copy`, by mentioning it as a separate item in the list of "additional implementors".
docs(marker/copy): provide example for `&T` being `Copy` ### Edited 2020-08-16 (most recent) In the current documentation about the `Copy` marker trait, there is a section with examples of structs that can implement `Copy`. Currently there is no example for showing that shared references (`&T`) are also `Copy`. It is worth to have a dedicated example for `&T` being `Copy`, because shared references are an integral part of the language and it being `Copy` is not as intuitive as other types that share this behaviour like `i32` or `bool`. The example picks up on the previous non-`Copy` struct and shows that structs can be `Copy`, even when they hold a shared reference to a non-`Copy` type. ----------------------------------------- ### Edited 2020-08-02, 3:28 p.m. I've just realized that it says "in addition to the **implementors listed below**", which makes this PR kind of "wrong", because `&T` is indeed in the "implementors listed below". Maybe we can instead show an example with `&T` in the [When can my type be Copy](https://doc.rust-lang.org/std/marker/trait.Copy.html#when-can-my-type-be-copy) section. What I really want to achieve is that it becomes more obvious that `&T` is also `Copy`, because, I think, it is very valuable to know and it wasn't obvious for me, until I read something about it in a forum post. What do you think? I would create another PR for that. **Please feel free to close this PR.** ----------------------------------- ### Original post In the current documentation about the `Copy` marker trait, there is a section about "additional implementors", which list additional implementors of the `Copy` trait. The fact that shared references are also `Copy` is mixed with another point, which makes it hard to recognize and make it seem not as important. This clarifies the fact that shared references are also `Copy`, by mentioning it as a separate item in the list of "additional implementors".
docs(marker/copy): provide example for `&T` being `Copy` ### Edited 2020-08-16 (most recent) In the current documentation about the `Copy` marker trait, there is a section with examples of structs that can implement `Copy`. Currently there is no example for showing that shared references (`&T`) are also `Copy`. It is worth to have a dedicated example for `&T` being `Copy`, because shared references are an integral part of the language and it being `Copy` is not as intuitive as other types that share this behaviour like `i32` or `bool`. The example picks up on the previous non-`Copy` struct and shows that structs can be `Copy`, even when they hold a shared reference to a non-`Copy` type. ----------------------------------------- ### Edited 2020-08-02, 3:28 p.m. I've just realized that it says "in addition to the **implementors listed below**", which makes this PR kind of "wrong", because `&T` is indeed in the "implementors listed below". Maybe we can instead show an example with `&T` in the [When can my type be Copy](https://doc.rust-lang.org/std/marker/trait.Copy.html#when-can-my-type-be-copy) section. What I really want to achieve is that it becomes more obvious that `&T` is also `Copy`, because, I think, it is very valuable to know and it wasn't obvious for me, until I read something about it in a forum post. What do you think? I would create another PR for that. **Please feel free to close this PR.** ----------------------------------- ### Original post In the current documentation about the `Copy` marker trait, there is a section about "additional implementors", which list additional implementors of the `Copy` trait. The fact that shared references are also `Copy` is mixed with another point, which makes it hard to recognize and make it seem not as important. This clarifies the fact that shared references are also `Copy`, by mentioning it as a separate item in the list of "additional implementors".
docs(marker/copy): provide example for `&T` being `Copy` ### Edited 2020-08-16 (most recent) In the current documentation about the `Copy` marker trait, there is a section with examples of structs that can implement `Copy`. Currently there is no example for showing that shared references (`&T`) are also `Copy`. It is worth to have a dedicated example for `&T` being `Copy`, because shared references are an integral part of the language and it being `Copy` is not as intuitive as other types that share this behaviour like `i32` or `bool`. The example picks up on the previous non-`Copy` struct and shows that structs can be `Copy`, even when they hold a shared reference to a non-`Copy` type. ----------------------------------------- ### Edited 2020-08-02, 3:28 p.m. I've just realized that it says "in addition to the **implementors listed below**", which makes this PR kind of "wrong", because `&T` is indeed in the "implementors listed below". Maybe we can instead show an example with `&T` in the [When can my type be Copy](https://doc.rust-lang.org/std/marker/trait.Copy.html#when-can-my-type-be-copy) section. What I really want to achieve is that it becomes more obvious that `&T` is also `Copy`, because, I think, it is very valuable to know and it wasn't obvious for me, until I read something about it in a forum post. What do you think? I would create another PR for that. **Please feel free to close this PR.** ----------------------------------- ### Original post In the current documentation about the `Copy` marker trait, there is a section about "additional implementors", which list additional implementors of the `Copy` trait. The fact that shared references are also `Copy` is mixed with another point, which makes it hard to recognize and make it seem not as important. This clarifies the fact that shared references are also `Copy`, by mentioning it as a separate item in the list of "additional implementors".
docs(marker/copy): provide example for `&T` being `Copy` ### Edited 2020-08-16 (most recent) In the current documentation about the `Copy` marker trait, there is a section with examples of structs that can implement `Copy`. Currently there is no example for showing that shared references (`&T`) are also `Copy`. It is worth to have a dedicated example for `&T` being `Copy`, because shared references are an integral part of the language and it being `Copy` is not as intuitive as other types that share this behaviour like `i32` or `bool`. The example picks up on the previous non-`Copy` struct and shows that structs can be `Copy`, even when they hold a shared reference to a non-`Copy` type. ----------------------------------------- ### Edited 2020-08-02, 3:28 p.m. I've just realized that it says "in addition to the **implementors listed below**", which makes this PR kind of "wrong", because `&T` is indeed in the "implementors listed below". Maybe we can instead show an example with `&T` in the [When can my type be Copy](https://doc.rust-lang.org/std/marker/trait.Copy.html#when-can-my-type-be-copy) section. What I really want to achieve is that it becomes more obvious that `&T` is also `Copy`, because, I think, it is very valuable to know and it wasn't obvious for me, until I read something about it in a forum post. What do you think? I would create another PR for that. **Please feel free to close this PR.** ----------------------------------- ### Original post In the current documentation about the `Copy` marker trait, there is a section about "additional implementors", which list additional implementors of the `Copy` trait. The fact that shared references are also `Copy` is mixed with another point, which makes it hard to recognize and make it seem not as important. This clarifies the fact that shared references are also `Copy`, by mentioning it as a separate item in the list of "additional implementors".
Rollup of 9 pull requests Successful merges: - rust-lang#75038 (See also X-Link mem::{swap, take, replace}) - rust-lang#75049 (docs(marker/copy): provide example for `&T` being `Copy`) - rust-lang#75499 (Fix documentation error) - rust-lang#75554 (Fix clashing_extern_declarations stack overflow for recursive types.) - rust-lang#75646 (Move to intra doc links for keyword documentation) - rust-lang#75652 (Resolve true and false as booleans) - rust-lang#75658 (Don't emit "is not a logical operator" error outside of associative expressions) - rust-lang#75665 (Add doc examples coverage) - rust-lang#75685 (Switch to intra-doc links in /src/sys/unix/ext/*.rs) Failed merges: r? @ghost
@poliorcetics @jyn514 Thank you for your swift responses and this fast merge!❤ It was my first contribution to Rust and I've felt very welcome. I hope, I can contribute some more in the future.🤗 |
No problem! Thanks for your contribution :) |
Thanks for the contribution :) if you continue to do docs PR you'll probably see us often ! Welcome to the open source world ! |
Edited 2020-08-16 (most recent)
In the current documentation about the
Copy
marker trait, there is a sectionwith examples of structs that can implement
Copy
. Currently there is no example forshowing that shared references (
&T
) are alsoCopy
.It is worth to have a dedicated example for
&T
beingCopy
, because sharedreferences are an integral part of the language and it being
Copy
is not asintuitive as other types that share this behaviour like
i32
orbool
.The example picks up on the previous non-
Copy
struct and shows thatstructs can be
Copy
, even when they hold a shared reference to a non-Copy
type.Edited 2020-08-02, 3:28 p.m.
I've just realized that it says "in addition to the implementors listed below", which makes this PR kind of "wrong", because
&T
is indeed in the "implementors listed below".Maybe we can instead show an example with
&T
in the When can my type be Copy section.What I really want to achieve is that it becomes more obvious that
&T
is alsoCopy
, because, I think, it is very valuable to know and it wasn't obvious for me, until I read something about it in a forum post.What do you think? I would create another PR for that.
Please feel free to close this PR.
Original post
In the current documentation about the
Copy
marker trait, there is a sectionabout "additional implementors", which list additional implementors of the
Copy
trait.The fact that shared references are also
Copy
is mixed with another point,which makes it hard to recognize and make it seem not as important.
This clarifies the fact that shared references are also
Copy
, by mentioning it as aseparate item in the list of "additional implementors".