Destructuring pt2 - confusion about temporary variables created in match statements
Nobody has claimed this yet.
Assessment
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Newbie friendliness
- 45/100
- Issue type
- Documentation
- Clarity
- Mostly clear
- Activity status
- Stale
- Tech stack
- rust
- Domain
- documentation
Research direction
Start with the “Destructuring pt2” section and compare the second and third code snippets, especially option 1 in each match statement. Verify how dereferencing interacts with copy and move semantics, then clarify whether a temporary is created and whether the value is copied or moved; the work is done when both examples explain the behavior consistently.
Written by the indexing model from the issue text.
Description
In Destructuring pt2, in the second code snippet, regarding the first option of the match statement, it says
"...in the first approach we dereference x to a temporary variable with type
Enum1(which copies the value inx)...".
Enum1 has copy semantics, so it makes sense that *x (the value in x) is copied into a temp variable. From that I conclude that if there is a match statement on a dereference of an object with copy semantics, a temporary variable is created and the value of *x is copied into it. So far so good.
However, in the third code snippet, option 1 of the match statement, where the value of x (now of type Enum2) has move semantics, shouldn't the same hold true, but this time, with a move operation, making this scenario illegal? That is, when creating a match statement on a dereference of an object with move semantics, it should, following the same logic, result in a temporary variable into which *x would be moved? Or does that not apply in case of object with move semantics? That is, if you have a match statements on a dereference of an object with move semantics, no temporary variable is created?
I don't know the answer as I'm just starting out with Rust and it gets me confused. I think this point should be clarified.
- Dominant language
- Rust
- Stars
- 3.9k
- Forks
- 297
- PR merge metrics
- No merged PRs in 30d
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from nrc/r4cppp
-
Difficulty 1/5 Under an hour Newbie friendliness 65/100
-
Difficulty 1/5 Under an hour Newbie friendliness 65/100
-
Difficulty 1/5 1-3 hours Newbie friendliness 68/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 38/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 42/100
Similar issues
-
Browser (wasm) relay client cannot connect to relays whose URL has a trailing-dot FQDN hostname Open
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
n0-computer/iroh#4550 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
paritytech/zombienet-sdk#591 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
farion1231/cc-switch#7638 · 1 comment ·
-
onnx-ir re-exports ModelProto and GraphProto but not NodeProto, AttributeProto and AttributeType Open
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100