Add long diagnostics for "bind by-ref and by-move"

[GuillaumeGomez]

Part of #24407.

[rust-highfive]

r? @pcwalton

(rust_highfive has picked a reviewer for you, use r? to override)

[Manishearth]

nit: s/binded/bound

Preferably keep "Copy" between backticks

[michaelsproul]

I think it's also more natural if we leave off the "than the others".

[Manishearth]

I'd prefer if code was marked as such, both with inline backticks and fences. It makes it easier to read.

Aside from that and a couple of nits, r=me

[GuillaumeGomez]

@Manishearth, @michaelsproul: Thanks for your comments ! I corrected what you pointed. Do you see remaining things that could be improved ?

[Manishearth]

"The goal here is to avoid binding simultaneous by-move and by-ref"

[Manishearth]

teensy bit

[michaelsproul]

I feel like this doesn't give a good reason for why bind by-move and by-ref are disallowed in the same pattern. Does anyone know? I've been unable to come up with an example that would violate memory safety. Partial moves are allowed by the compiler, which seem almost identical. Is this error due to a limitation in the compiler's ability to reason about data-overlap in patterns?

[Manishearth]

I feel like this doesn't give a good reason for why bind by-move and by-ref are disallowed in the same pattern. Does anyone know why?

So if we have (x, ref y), we invalidate the tuple with the move out via x, but we still need the tuple to exist for the ref y to work.

[GuillaumeGomez]

@michaelsproul: Hum... Don't you think it would be too much ? I thought here was to give a help to the developer in order to make him understand what he made wrong and how to fix it.

[michaelsproul]

@GuillaumeGomez: I think meaningful justifications both help people learn and make them happier to follow recommendations.

@Manishearth: I thought that too, but essentially the same thing works if you do it step by step:

fnmain(){let p = ("x".to_string(),"y".to_string());let(_,ref y) = p;let(x, _) = p;println!("{} {}", x, y);}

[Manishearth]

Huh. That should work then.

[michaelsproul]

This line is longer than 80 characters, might be best flowing across the next line:

There are two possible solutions.
1. Implement the `Copy` trait for the X structure:
// Code here
2. Bind the pattern's names the same way:
// Code here

(there's also a "the the" in the current version of the second case)

[michaelsproul]

Thanks for doing this, sorry about the endless comments! 😄

(I avoided this error specifically because it looked hard)

[GuillaumeGomez]

@michaelsproul: No problem, it's very kind of you to help me like this ! I actually took this error because I didn't know what it was, I discovered a whole new type of errors haha.

[ghost]

I don't think this is a particularly good piece of advice. While it does indeed make the code in question compile, implementing Copy is often undesirable (such as for wide structures) and has its own set of ramifications that we should perhaps expand on here, or link to a document that does that.

[GuillaumeGomez]

I see your point. Should I precise that it would be better to do the second solution ?

[Manishearth]

Yes, and make the second solution the first solution.

[GuillaumeGomez]

@jakub- @Manishearth: Done. Do you see anything else ?

[GuillaumeGomez]

And it's good. If anyone does see something else to change, please just ask !

[alexcrichton]

Thanks! Could you squash the commits together as well?

[GuillaumeGomez]

@alexcrichton: Done !

[alexcrichton]

@bors: r+ 9a15234

[alexcrichton]

@bors: rollup

[bors]

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

[GuillaumeGomez]

I resolved the conflicts.

[alexcrichton]

@bors: r+ cf53f03

[alexcrichton]

Closing in favor of the merged version at #24542