Chapter 6.2 - Context or alternative examples to illustrate `None` usage
julix-unity opened this issue · comments
- I have searched open and closed issues and pull requests for duplicates, using these search terms:
- chapter 6
- 6
- six
- matching with option
- I have checked the latest
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
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.
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!