Uh oh!
There was an error while loading. Please reload this page.
Make Point Copy in arithmetic documentation - #69766
Conversation
rust-highfive
commented
Mar 6, 2020
r? @shepmaster (rust_highfive has picked a reviewer for you, use r? to override) |
shepmaster
left a comment
There was a problem hiding this comment.
I'd prefer the common order of these traits that I have seen.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
shepmaster
commented
Mar 7, 2020
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? |
rust-highfive
commented
Mar 10, 2020
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 |
Uh oh!
There was an error while loading. Please reload this page.
skade
commented
Mar 10, 2020
@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. |
shepmaster
commented
Mar 10, 2020
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
69aaed8Compare@shepmaster thank you! Squashed! |
shepmaster
commented
Mar 10, 2020
@bors r+ rollup |
bors
commented
Mar 10, 2020
📌 Commit 69aaed8 has been approved by |
bors
commented
Mar 10, 2020
🌲 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
Copyon 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.