-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
Make Point Copy
in arithmetic documentation
#69766
Make Point Copy
in arithmetic documentation
#69766
Conversation
r? @shepmaster (rust_highfive has picked a reviewer for you, use r? to override) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd prefer the common order of these traits that I have seen.
It's pure pedantry, but since the operands don't appear to be used after the operation (and they couldn't have been because they weren't It comes down to the typical sci-fi dilemma: which of the two values is the copy and which is the original? |
The job Click to expand the log.
I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
@shepmaster Interesting, I couldn't find a reference to that order somewhere. Most codebases I use put Clone before Copy. (prerequisite in front) In any case, your order reads well and puts the Copy more upfront. |
Looks good to me; squash things together and we will merge! |
Small composite types like `Point { x: i32, y: i32}` are plain old data and we should encourage users to derive `Copy` on them. This changes the semantics of the edited examples slightly: instead of consuming the operands during addition, it will copy them. This is desired behaviour. Co-Authored-By: Jake Goulding <shepmaster@mac.com>
6c24574
to
69aaed8
Compare
@shepmaster thank you! Squashed! |
@bors r+ rollup |
📌 Commit 69aaed8 has been approved by |
🌲 The tree is currently closed for pull requests below priority 1000, this pull request will be tested once the tree is reopened |
…ntation, r=shepmaster Make Point `Copy` in arithmetic documentation Small composite types like `Point { x: i32, y: i32}` are plain old data and we should encourage users to derive `Copy` on them. This changes the semantics of the edited examples slightly: instead of consuming the operands during addition, it will copy them. This is desired behaviour.
Rollup of 10 pull requests Successful merges: - #66059 (mem::zeroed/uninit: panic on types that do not permit zero-initialization) - #69373 (Stabilize const for integer {to,from}_{be,le,ne}_bytes methods) - #69591 (Use TypeRelating for instantiating query responses) - #69625 (Implement nth, last, and count for iter::Copied) - #69645 (const forget tests) - #69766 (Make Point `Copy` in arithmetic documentation) - #69825 (make `mem::discriminant` const) - #69859 (fix #62456) - #69891 (Exhaustiveness checking, `Matrix::push`: recursively expand or-patterns) - #69896 (parse: Tweak the function parameter edition check) Failed merges: r? @ghost
Small composite types like
Point { x: i32, y: i32}
are plainold data and we should encourage users to derive
Copy
on them.This changes the semantics of the edited examples slightly: instead
of consuming the operands during addition, it will copy them. This
is desired behaviour.