You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Description of the problem:
The plus_one with None example feels abstract, it's not clear why the match is needed there at all, since the function works fine without:
fn plus_one(x: i32) -> i32 {
x + 1
}
The previous example with the coins (even sorting by state) felt so applied that the contrast to this much more artificial example is jarring.
[aside] Additional context: My brain might be JavaScript poisoned where type coercion is rampant. Therefor if I called a plus_one with no arguments I'd expect it to either to return "one more than nothing "(1) as a fallback or better to error explicitly complaining about lack of valid arguments - probably same with null. [/aside]
Suggested fix:
I don't have a great solution, since I don't really know when None happens in Rust.
Could we provide context for how/why plus_one might receive a value that is currently invalid or absent for some reason. Maybe it's already a natural example and it just feels arbitrary to me since I don't understand how x became None (other than for demo purposes).
Or if it isn't, could we use a different example where None would happen naturally? ChatGPT suggested optional configuration settings, where a function might need to handle an Option to account for both specified and unspecified (or default) settings (it claimed that was a common case across domains, and I guess it reminds me of user input from forms with "prefer not to say" as an option, so if there's a Rust equivalent perhaps it's good).
Intention:
I'm hoping that by raising what caused friction for me perhaps we can smooth transition into Rust for folks that are new or like me come from dynamic programming languages like JS.
The text was updated successfully, but these errors were encountered:
Thanks for opening this! I can understand what you mean about the shift between the very real-world-feeling example of the coins to the more abstract plus_one. I am not sure if we will end up significantly changing this, but for reference, the way to think about it coming from JS or similar is: all the places where you can imagine having some value be undefined or null is a place where you would have an Option in Rust instead. That could be user-entered data, data from an API which is allowed to be missing, etc. Part of the goal here, I think, is to keep the sample code simple enough that it does not require introducing any other “support” code around it, but I think we might be able to finagle a small additional bit of text to motivate it if we think it is a significant enough stumbling block. At a minimum, we will chat and think on it. Thanks for the feedback!
main
branch to see if this has already been fixed, in this file:URL to the section(s) of the book with this problem:
https://doc.rust-lang.org/book/ch06-02-match.html#matching-with-optiont
Description of the problem:
The
plus_one
withNone
example feels abstract, it's not clear why thematch
is needed there at all, since the function works fine without:The previous example with the coins (even sorting by state) felt so applied that the contrast to this much more artificial example is jarring.
[aside]
Additional context: My brain might be JavaScript poisoned where type coercion is rampant. Therefor if I called aplus_one
with no arguments I'd expect it to either to return "one more than nothing "(1
) as a fallback or better to error explicitly complaining about lack of valid arguments - probably same withnull
.[/aside]
Suggested fix:
I don't have a great solution, since I don't really know when
None
happens in Rust.Could we provide context for how/why
plus_one
might receivea value that is currently invalid or absent for some reason.
Maybe it's already a natural example and it just feels arbitrary to me since I don't understand howx
becameNone
(other than for demo purposes).Or if it isn't, could we use a different example where
None
would happen naturally? ChatGPT suggested optional configuration settings, where a function might need to handle an Option to account for both specified and unspecified (or default) settings (it claimed that was a common case across domains, and I guess it reminds me of user input from forms with "prefer not to say" as an option, so if there's a Rust equivalent perhaps it's good).Intention:
I'm hoping that by raising what caused friction for me perhaps we can smooth transition into Rust for folks that are new or like me come from dynamic programming languages like JS.
The text was updated successfully, but these errors were encountered: