Mention Clone and refs in --explain E0382

[jacwah]

I followed the discussion in #42446 and came up with these additions.

• Mention references before going into traits. They're probably more likely solutions.
• Mention Clone before Copy. Cloning has wider applicability and #derive[Copy, Clone] makes more sense after learning about Clone.

The language is not great, any suggestions there would be appreciated ✨

[rust-highfive]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @eddyb (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.

[eddyb]

How do I keep getting assigned to suggestion PR?! r? @nikomatsakis

[nikomatsakis]

I am trying to figure out how to tie in the copy vs clone dichotomy a bit better here. I think it's useful to explain when you would want what. I sometimes mention a three-level grouping here:

• Default: represents a unique resource
  • Example: Money
• Implements Clone: represents a resource, but one that can be copied
  • Example: Vector, String
• Implements Copy and Clone: represents a value with no ownership semantics
  • Example: integer

I am torn between keeping the presentation as you did it -- with one type (MyStruct) that grows impls -- versus changing to give a bit more semantics context. For example, one could have struct MyStruct { values: Vec<u32> } for clone and change to struct Point { x: u32, y: u32 } or something as an example where Copy would be appropriate.

Really, I'd prefer to tag in somebody like @steveklabnik or @carols10cents here -- it seems like we should work hard to ensure that this extended error message ties in well with the way that the book explains things.

[jacwah]

Yeah, I think giving better examples is a good idea. Clone vs Copy is explained as heap vs stack data in the book. I'm not sure this is the best way to go about it though. I like your explanation better, focusing on semantics instead of low-level memory layout which may be less familiar to a newcomer.

[steveklabnik]

I also like Niko's framing as well; the book tries to do a fairly low-level explanation, but once you grasp that, the higher-level one is better, IMO.

[nikomatsakis]

r? @steveklabnik

[carols10cents]

Around here is where we first discuss Clone/Copy in the book.

[steveklabnik]

I'd be okay with merging this, but if you want to try something like @nikomatsakis suggested, I'd be open to it as well.

[jacwah]

@nikomatsakis @steveklabnik I updated some of the examples. They hopefully show the use cases for different strategies a bit better.

[kennytm]

You mean let p2 = p1; here?

[01:14:25] ---- /checkout/obj/build/x86_64-unknown-linux-gnu/test/error-index.md - Rust_Compiler_Error_Index (line 6184) stdout ----
[01:14:25] 	error[E0425]: cannot find value `p2` in this scope
[01:14:25]  --> /checkout/obj/build/x86_64-unknown-linux-gnu/test/error-index.md:6:13
[01:14:25]   |
[01:14:25] 6 |     let y = p2;
[01:14:25]   |             ^^ did you mean `p1`?
[01:14:25] 
[01:14:25] error[E0425]: cannot find value `p2` in this scope
[01:14:25]  --> /checkout/obj/build/x86_64-unknown-linux-gnu/test/error-index.md:9:28
[01:14:25]   |
[01:14:25] 9 |     println!("p2: {}, {}", p2.x, p2.y);
[01:14:25]   |                            ^^ did you mean `p1`?
[01:14:25] 
[01:14:25] error[E0425]: cannot find value `p2` in this scope
[01:14:25]  --> /checkout/obj/build/x86_64-unknown-linux-gnu/test/error-index.md:9:34
[01:14:25]   |
[01:14:25] 9 |     println!("p2: {}, {}", p2.x, p2.y);
[01:14:25]   |                                  ^^ did you mean `p1`?
[01:14:25] 
[01:14:25] thread 'rustc' panicked at 'couldn't compile the test', /checkout/src/librustdoc/test.rs:283:12

[bors]

☔ The latest upstream changes (presumably #45167) made this pull request unmergeable. Please resolve the merge conflicts.

[jacwah]

I squashed and rebased the work on master. Should be good to go :)

[steveklabnik]

Thanks a ton!

@bors: r+ rollup

[bors]

📌 Commit 47ea51e has been approved by steveklabnik