Skip to content
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

Enums3 rustling is unclear #1545

Open
ScottSpalding opened this issue Jun 7, 2023 · 3 comments · May be fixed by #1774
Open

Enums3 rustling is unclear #1545

ScottSpalding opened this issue Jun 7, 2023 · 3 comments · May be fixed by #1774

Comments

@ScottSpalding
Copy link

I've been stuck on the enums3 rustling, specifically around matching on Move() and feel like compared to all prior exercises it is unclear. I think naturally you start with "Message::Move() => {" and iterate from there. The rust documentation doesn't detail how to do this kind of matching here: https://doc.rust-lang.org/book/ch06-02-match.html (maybe it's somewhere else that I missed?)

Regardless, iterating from there, you eventually can stumble into Message::Move{x, y} => { which compiles, at least. Which leads to frustration two - how to process the match. Iterating through the error messages, I eventually ran into self.move_position(Point{x:x.try_into().unwrap(), y:y.try_into().unwrap()});

Which leads to an error in the test at line 75, "not a value". This error message isn't super clear (I assume it's native rust, not part of the rustlings project, but still worth mentioning), and it's not clear what to do from here. The hints aren't super helpful, though I assume what I need to do is some kind of deconstruction/construction. However, I've brute-forced through each decon/con pairing I can think of and none of them have worked, without really any indication of what is the proper one either through documentation or error messages.

I realize that self.move_position(Point{x:x.try_into().unwrap(), y:y.try_into().unwrap()}); contrasts with what the "Remember:" hint seems to be implying the answer should be - something like self.move_position((x, y));, but I could never get any variation of that to compile. Further, it's confusing to have the 'fn' characters there - this seems to be implying that when you're defining a function with a tuple parameter you need the extra paratheses, but for this exercise you're not defining any functions.

Regardless of how my tone may sound, I appreciate the immense amount of work that's gone into this project and am only trying to improve it.

@shadows-withal
Copy link
Member

Some hints from my side, maybe:

  • Three of those enum variants (except Quit) hold type arguments, Move holds a Point, Echo holds a String, and ChangeColor holds three u8's
  • A match statement allows you to bind variant arguments to variables, therefore you can simply write Message::Move(point) => etc as a match arm without having to specify what type it is or how it's constructed (the compiler knows based on your enum definition)
  • All the functions for processing the message types are already defined, and can be called like this, for example: self.move_position(point)

Hope this helps, it's important to remember that match statements in Rust are usually used to pattern match, which might not be a concept present in other programming languages.

@ScottSpalding
Copy link
Author

ScottSpalding commented Jun 12, 2023

That I knew. Here's what my problem was. In enums2, I had this code in my enum Message declaration/definition, and it worked:
Move{x:i32,y:i32}

while I think in enums3, there's no way to proceed with that definition (I think, at least), and instead you need to use:
Move(Point)

Not sure if this is WAI or not, but it seems strange to me that code that was valid for one problem was invalid for a later problem.

@shadows-withal
Copy link
Member

Hmm, I get what you mean, yeah. There's a bit of a big jump between enums2 and enums3 where we define a struct that replaces the two enum variant argument fields from the previous exercise.

I don't personally think this is a huge deal (they are two different exercises after all), but I'd be happy to merge a PR that lowers the gap between those two exercises.

matthri added a commit to matthri/rustlings that referenced this issue Nov 14, 2023
@matthri matthri linked a pull request Nov 14, 2023 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants